LINUX.ORG.RU

Вышел Rust 1.23

 ,


2

9

4 января состоялся плановый релиз компилятора и стандартных средств разработки системного языка программирования Rust — 1.23.

Интересные изменения:

  • За счёт предотвращения ненужного копирования аргументов функций уменьшено потребление памяти. Например сам компилятор rustc стал потреблять на 5-10% меньше памяти.
  • rustdoc перешёл на рендеринг документации при помощи CommonMark. Раньше использовался Hoedown.
  • The Cargo Book переехал с doc.crates.io на doc.rust-lang.org и обновил формат.
  • cargo uninstall научился сразу удалять несколько пакетов. Например, команда cargo uninstall foo bar удалит foo и bar.
  • auto трейты теперь разрешены в трейтовых объектах. Один из коммитов этого изменения также окончательно удалил элемент языка send.
  • Проверки типов операндов бинарных операторов теперь производится относительно левого операнда, что предотвращает путаницу в соответствующих сообщениях об ошибках.
  • Исключена необходимость в T: Sync для RwLock<T>: Send.
  • Исключена необходимость в T: Sized для {<*const T>, <*mut T>}::as_ref и для <*mut T>::as_mut.
  • Оптимизирована реализация Thread::{park, unpark}.
  • Улучшена производительность SliceExt::binary_search.
  • Трейт AsciiExt объявлен устаревшим, а его методы перенесены в примитивные типы.
  • char::escape_debug теперь использует Unicode 10 вместо Unicode 9.
  • Включён LLVM-флаг TrapUnreachable.
  • musl, используемый для сборки musl rustc, обновлён до 1.1.17.
  • Улучшена производительность SliceExt::binary_search.
  • rustfmt включён в основную инсталляцию.
  • Минимальная версия LLVM изменена на 3.9.

Полный перечень изменений

>>> Анонс

★★★★★

Проверено: Shaman007 ()
Последнее исправление: tailgunner (всего исправлений: 5)

Ответ на: комментарий от khrundel

Что, припекает, когда узнал, что сам - хипстер?

Так у тебя и надо спросить это.

awesomelackware
()
Ответ на: комментарий от I60R

А ещё там нет наследования, сборки мусора и динамической >типизации. Убожество

Наследование нужно, хотя бы для интерфейсов.
Без сборки мусора можно обойтись
Динамическая типизация не показатель.

upd. ещё конструкторов нет

Гонишь. Это же былинный отказ.

ox55ff ★★★★★
()
Ответ на: комментарий от bbk123

В С деструкторов нет, потому что там автоматическое управление памятью?

А в rust есть типаж Drop. В java есть метод finalize.

O02eg ★★★★★
()
Ответ на: комментарий от ox55ff

Гонишь. Это же былинный отказ.

Правда нету. Как без исключений возвращать ошибки из конструкторов?

Есть inherent methods без параметра self. Пример:

impl File {
   pub fn open(file_name: &str) -> Result<File, Error> { ... }
}
red75prim ★★★
()
Ответ на: комментарий от bbk123

Ты сам-то понял, зачем это сказал?

А ты понял что я сказал?

Да. Так ты понял-то, зачем привел эту нерелевантную информацию?

Нет, память может закончится не в любой функции, а только в тех, которые ее выделяют.

Что за чушь? Любой вызов функции, кроме разве что inline функции, как минимум алоцирует память на стеке.

Когда говорят «закончится память», очень редко имеют в виду стек. Но, если ты имел в виду стек - да, он может закончится при вызове любой функции. И это ровно никак не влияет на желание помечать функции, в которых паника вызывается явно.

И, возможно, моя задача - не вызвать случайно функцию, которая выделяет память.

Если ты говоришь о памяти в куче, то объясни практический смысл этого твоего желания?

Работа в условиях исчерпанной или разрушенной кучи.

что за одержимость исчерпанием памяти? Ты почему-то думаешь, что это единственная ошибка, которая может привести к панике?

В каком месты ты увидел одержимость? Это всего лишь пример

Это единственный пример, о котором ты говоришь, причем постоянно.

Как ты можешь засунуть более одного типа в E?

Я оставлю это тебе в качестве упражнения по Rust. Намек: я не говорю о том, чтобы E был enum.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Работа в условиях исчерпанной или разрушенной кучи.

Ещё обработчики сигналов могут требовать отсутствие выделений.

O02eg ★★★★★
()
Ответ на: комментарий от dzidzitop

кто тебе сказал что формата машины?

по другому не видел

ты знаешь на какой машине твой код будет выполняться?

зачем?

Ты бы хоть одно переполнение инта под все возможные форматы и платформы обработал в соответствии со стандартом своего любимого C - узнал бы по чём фунт лиха.

// returns true if (a+x) will overflow or underflow
int addo(int a, int x) {
    if ((x > 0) && (a > INT_MAX - x))
        return 1;
    if ((x < 0) && (a < INT_MIN - x))
        return 1;
    return 0;
}

обработал, где фунт лиха?
INT_MAX и INT_MIN из стандартного limits.h

А машиннонезависимый код ты не писал вообще никогда на этом язычке. Иначе бы не писал этой чуши.

только что написал такой код

anonymous
()
Ответ на: комментарий от anonymous

по другому не видел

т.е. придумал сам.

зачем?

т.е. пишешь код под свой локалхост.

обработал, где фунт лиха?

1) в каждом месте реального код отработал?
2) получил хорошую производительность при этом?

только что написал такой код

поздравляю! осталось переписать на мультиплатформу все те гигабайты кода, которые ты написал до этого. а потом окинуть результат взором, оценить производительность и заплакать.

Как ты понимаешь, переполнение целого - это далеко не единственная изюминка этого чудо-язычка.

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

маленькая поправка там должен быть 'least'

ну или парируй цитатой из стандарта C.

ISO/IEC 9899:1999 &7.18.1.2.3

The following types are required:
int_least8_t int_least16_t int_least32_t int_least64_t
uint_least8_t uint_least16_t uint_least32_t uint_least64_t
All other types of this form are optional.

anonymous
()
Ответ на: комментарий от tailgunner

нет, этого не достаточно. Таких мест где автор «думает» что может быть паника слишком много. Часть из них llvm сможет доказать как недостижимые, и реальный список будет намного короче.

pftBest ★★★★
()
Ответ на: комментарий от red75prim

Это не деструктор, это аналог finalizer-а в Java. Ничего более страшного, чем завершение программы, не произойдёт. При этом все остальные drop-ы скорее всего отработают. Например если запустить этот код:

struct DropObj1 {
    pub dobj: DropObj2
}

struct DropObj2;

impl Drop for DropObj1 {
    fn drop(&mut self) {
        println!("DropObj1: will panic in drop");
        panic!();
    }
}

impl Drop for DropObj2 {
    fn drop(&mut self) {
        println!("DropObj2: will not panic in drop")
    }
}

fn main() {
    DropObj1 { dobj: DropObj2 };
    println!("Finishing program normally");
}

программа напечатает сообщение из первого дропа, затем стектрейс, затем сообщение из второго дропа и остановится, не напечатав завершающее сообщение.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

int_least8_t - это совсем не int8_t. совершенно неопределённая разрядность и гарнтии на диапазон допустимых значений и поразрядную арифметику и занимаемую память.

Но я понял о чём ты. i32 в расте - это 32 разряда. А int_least32_t - это «от 32 разрядов».

dzidzitop ★★
()
Ответ на: комментарий от MyTrooName

Продакшон чуток потестил, чтоб не падал совсем уж часто и норм. Да и чего ему падать, ГЦ же. А в поганом расте нужно с компилятором договариваться и каждое изменение отражать.

khrundel ★★★★
()
Ответ на: комментарий от pftBest

что ты сам не знаешь есть у тебя паника тут или нет.

Ты знаешь, что автор кода считает ее возможной. Этого достаточно.

нет, этого не достаточно

Совершенно очевидно, что таким образом все паники будут помечены, поэтому и сказано «достаточно» (не «минимально необходимо», а «достаточно»). Если ты считаешь по-другому - обоснуй.

Таких мест где автор «думает» что может быть паника слишком много.

Ты их считал?

Часть из них llvm сможет доказать как недостижимые, и реальный список будет намного короче.

И что? Продолжи свою мысль. В частности, объясни вот это:

pftBest> Нет, нельзя, потому что ты сам не знаешь есть у тебя паника тут или нет.

Интересует «нельзя» - это значит, что лично ты запрещаешь? Или существуют какие-то технические основания, которые это запрещают?

tailgunner ★★★★★
()
Ответ на: комментарий от O02eg

В С деструкторов нет, потому что там автоматическое управление памятью?

Для непонятливых мне надо было написать «общее свойство объектно-ориентированных языков с автоматическим управлением памяти».

В java есть метод finalize.

Который не деструктор и вообще редко когда используется.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от dzidzitop

Как ты понимаешь, переполнение целого - это далеко не единственная изюминка этого чудо-язычка.

переполнения флоатов в кастах и арифметке в вашем чудо-языке как раз таки UB.
А в C есть возможность вляить на поведение при ошибках с флоатами, обрабатывать как сигналы и настраивать их округление. Конечно эта витча опциональна, не на всех микроконтроллерах это возможно, но в пост-юниксах работает. см. fenv.h

anonymous
()
Ответ на: комментарий от ox55ff

сначала приятно пробрасывать исключения вверх стеку, потом приятно перевыбрасывать исключения из обработчика исключений, потом приятно выбрасывать исключения из конструктора, а потом приятно долбиться в дымоход с таким же любителем приятных особенностей. следи за собой, будь осторожен.
anonymous (05.01.2018 19:39:17)

на какой ты уже стадии? что следующее по списку?

anonymous
()
Ответ на: комментарий от red75prim

Как без исключений возвращать ошибки из конструкторов?

так же как и из любой другой функции, вторым аргументом.

желаю вам с ox55ff любви и счастья.

anonymous
()
Ответ на: комментарий от RazrFalcon

Почему не деструктор? С каким деструктором вы сравниваете?

Потому что в JVM освобождение памяти от других объектов, на которые ссылается данный объект, от метода finalize() не зависит. Полагаю, что в случае с drop всё так же. По этой же причине программисты на Java не боятся бросать исключения в конструкторе, чего не любят делать программисты на C++.

bbk123 ★★★★★
() автор топика
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от anonymous

на какой ты уже стадии?

Ни на какой. Мань, ты не до конца протрезвел? Не проецируй на меня свои пристрастия.

ox55ff ★★★★★
()
Ответ на: комментарий от anonymous

так же как и из любой другой функции, вторым аргументом.

Главное потом не забыть этот зомби-объект уничтожить. И предусмотреть механизм отключения вызова деструкторов для недоконструированных полей.

red75prim ★★★
()
Ответ на: комментарий от dzidzitop

получил хорошую производительность при этом?

ну мой пример конечно не идеально в плане производительности работает, но можно воспользоваться GNU C расширением и получить нативную проверку на каждой архитектуре взамен на совместимость только с gcc и clang но это всёрано охватывает больше платформ чем rustc

anonymous
()
Ответ на: комментарий от red75prim

Главное потом не забыть этот зомби-объект уничтожить.

сборщик мусора для этого нужен. все гости собрались, давайте уже, когда у вас свадьба.

anonymous
()
Ответ на: комментарий от anonymous

переполнения флоатов в кастах и арифметке в вашем чудо-языке как раз таки UB.

А в вашем э то определено на уровне языка? Можно ссылку?

А в C есть возможность вляить на поведение при ошибках с флоатами

Прямо как в Rust.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Хорошо, приведу пример. Вот смотришь ты на такую строку в коде:

    let x = a[b];

Будет тут паника или нет? может и быть а может и нет. Если анализировать только пометки в сигнатурах функций и операторов, то точно есть. Но на самом деле это будет бесполезным ложным срабатыванием если выше по коду есть проверка:

    if b >= a.len() {
        return Err(());
    }
    let x = a[b];

Тут уже никакой паники не будет, но доказать это сможет только сам llvm при оптимизации.

А если бы я хотел чтобы паники тут не было, но ошибся, и написал > вместо >= то я бы «думал» что паники не будет, но на самом деле она есть, и llvm знает об этом, а человек нет. Именно это я и имел в виду.

pftBest ★★★★
()
Ответ на: комментарий от pftBest

Ты сказал, что нельзя добавлять с игнатуры функций пометку «тут возникает паника». Я в очередной раз спрашиваю - почему нельзя?

Будет тут паника или нет?

Это неважно. Функция должна быть помечена как потенциально паникующая.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да. Так ты понял-то, зачем привел эту нерелевантную информацию?

Значит ты не понял. Ты написал: «Исключение можно перехватить всегда, панику - зависит». Вот про это «зависит» я и написал. Кстати, на сколько я понимаю, панику в Rust тоже можно перехватить:
https://doc.rust-lang.org/std/panic/fn.set_hook.html

Когда говорят «закончится память», очень редко имеют в виду стек.

Иметь в виду могут что угодно. Например в JVM может закончиться память PermGen.

И это ровно никак не влияет на желание помечать функции, в которых паника вызывается явно.

Что ты собираешься делать с такими помечеными функциями из стандартной библиотеки? Метить все функции, которые их вызывают. Я насчитал там 517 мест, где panic! вызывается явно. Подумай, почему java.lang.Error, java.lang.RuntimeException и их наследники в Java относятся к unchecked.

Работа в условиях исчерпанной или разрушенной кучи.

Разве в этом случае работа вообще возможна?

Это единственный пример, о котором ты говоришь, причем постоянно.

Вообще-то примеры должен был давать тот, кто хочет помечать функции с возможной паникой. Я лишь упомянул первое, что пришло в голову.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Ты написал: «Исключение можно перехватить всегда, панику - зависит». Вот про это «зависит» я и написал

Ты написал про Java, которая к разговору вообще отношения не имеет.

Панику в Rust тоже можно перехватить:

Можно. Если есть поддержка в рантайм-библиотеке и ты не собрал программу с panic=abort. Вот именно поэтому и «зависит». С чего ты начал притягивать Java - даже ты не знаешь.

Я насчитал там 517 мест, где panic! вызывается явно

И?

Работа в условиях исчерпанной или разрушенной кучи.

Разве в этом случае работа вообще возможна?

Да, конечно. А если ты не считаешь отправку сообщения о фатальном сбое работой - это твоя проблема.

Вообще-то примеры должен был давать тот, кто хочет помечать функции с возможной паникой

Тебе дали как минимум 3 примера.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Насколько я знаю, drop работает так же, как и в C++. Разве что у его можно «отключить» через mem::forget.

Он работает так, как ты его напишешь. Но поскольку автоматического управления памятью в C++ нет, от реализации деструкторов в C++ зависит и управление памятью. А вот в языках с автоматическим управлением памятью такой зависимости нет. Метод finalize() если и нужен, то совсем для другого и рассматривать его как аналог деструктора совершенно неправильно. Не вижу как drop в Rust может отличаться от finalize() в Java.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Ты сказал, что нельзя добавлять с игнатуры функций пометку «тут возникает паника».

А что, уже есть такой синтаксис в языке?

Функция должна быть помечена как потенциально паникующая.

И получится слишком много ложных срабатываний на уровне бесполезности. Потому что паникующая функция заражает все остальные выше по стеку, так что у тебя будет вся программа в сигнатурах «тут возникает паника», включая функцию main.

Я хочу иметь совсем другой инструмент, нужно получить список только тех функций где на самом деле есть паника, а не «потенциально», и те которые доказать нельзя, но с существованием которых я согласен, добавить в белый список и следить чтобы при написании кода не появлялись новые.

pftBest ★★★★
()
Ответ на: комментарий от tailgunner

Можно. Если есть поддержка в рантайм-библиотеке и ты не собрал программу с panic=abort. Вот именно поэтому и «зависит». С чего ты начал притягивать Java - даже ты не знаешь.

Поддержка уже есть в стандартной библиотеке. Если ты собираешь с panic=abort, то что тебе дадут твои метки? Java я никуда не притягивал, а использовал для сравнения.

> Я насчитал там 517 мест, где panic! вызывается явно
И?

И что ты собрался делать с метками в этих местах? Рекурсивно метить все остальные функции, которые их вызывают?

Да, конечно. А если ты не считаешь отправку сообщения о фатальном сбое работой - это твоя проблема.

У тебя и так есть это сообщение от panic. Какую ещё работу ты хочешь сделать? Переслать стактрейс на email при помощи фатально умирающей программы?

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Поддержка уже есть в стандартной библиотеке.

Где-то есть, где-то нет.

Если ты собираешь с panic=abort, то что тебе дадут твои метки?

Моя программа не завершится там, где мне это не нужно.

Java я никуда не притягивал, а использовал для сравнения.

Никто не просил тебя о сравнении, особенно таком бессмысленном.

Да, конечно. А если ты не считаешь отправку сообщения о фатальном сбое работой - это твоя проблема.

У тебя и так есть это сообщение от panic.

А что, panic отправляет сообщение по сети серверу статистики?

Переслать стактрейс на email при помощи фатально умирающей программы?

Примерно так, да. Ты запрещаешь?

tailgunner ★★★★★
()
Ответ на: комментарий от pftBest

Ты сказал, что нельзя добавлять с игнатуры функций пометку «тут возникает паника».

А что, уже есть такой синтаксис в языке?

Так проблема в этом, а не в оптимизации LLVM?

Функция должна быть помечена как потенциально паникующая.

И получится слишком много ложных срабатываний на уровне бесполезности.

Не получится. В местах, где паника недопустима, будет использоваться не foo, а foo.get(i).

Я хочу иметь совсем другой инструмент, нужно получить список только тех функций где на самом деле есть паника

Следи за предупреждениями компилятора о недостижимом коде.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Где-то есть, где-то нет.

Про что ты сейчас говоришь? std::panic::set_hook есть везде, где есть Rust не ниже 1.10

Моя программа не завершится там, где мне это не нужно.

Тоесть на самом деле ты не хочешь panic=abort

Никто не просил тебя о сравнении, особенно таком бессмысленном.

Тебя тоже никто не просил предлагать совершенно бессмысленную идею о метке функций с возможным вызовом panic.

А что, panic отправляет сообщение по сети серверу статистики?
Примерно так, да. Ты запрещаешь?

Да, мне не нравятся архитектурно глупые решения. Оправданием для вызова panic служит лишь полная невозможность продолжать работу. Если ты всё ещё можешь отправлять сообщения по сети или слать email-ы, то очевидно, что вызов panic неоправдан и если он всё же происходит, то это баг.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

При чём тут java?

При том, что там тоже автоматическое управление памятью.

Что такого можно сделать в деструкторе в C++, чего нельзя в Rust?

В drop нельзя вручную управлять памятью, это же очевидно.

bbk123 ★★★★★
() автор топика
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от bbk123

Где-то есть, где-то нет.

Про что ты сейчас говоришь?

Про рантайм-поддержку.

std::panic::set_hook есть везде, где есть Rust не ниже 1.10

Ты точно читал документацию? «the hook will run with both the aborting and unwinding runtimes», а потом программа завершится, если у тебя aborting runtime.

Моя программа не завершится там, где мне это не нужно.

Тоесть на самом деле ты не хочешь panic=abort

То есть я хочу, чтобы программа не зависела от panic=xxx

Ты запрещаешь?

Да

Ты не можешь никому ничего запретить.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

То есть я хочу, чтобы программа не зависела от panic=xxx

Тебе кто-то запрещает использовать что-то другое, кроме abort?

Ты не можешь никому ничего запретить.

Разумеется, физически не могу. Я просто считаю архитектурно глупые решения глупыми и стараюсь их избегать

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

> В drop нельзя вручную управлять памятью, это же очевидно.

Ты снова что-то запрещаешь?

Расскажи мне про ручное управление памятью в Rust.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Тебе кто-то запрещает использовать что-то другое, кроме abort?

Почему ты считаешь, что я пишу программу исключительно для себя? Почему ты считаешь, что на целевой платформе уже реализован unwinding runtime?

Я просто считаю архитектурно глупые решения глупыми

Не думаю, что ты уже можешь здраво судить о глупости архитектурных решений.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Почему ты считаешь, что на целевой платформе уже реализован unwinding runtime?

На какой не реализован?

Не думаю, что ты уже можешь здраво судить о глупости архитектурных решений.

Судя по тому, что аргументы у тебя закончились и ты банально перешёл на личности, я таки прав. Но всё таки, ты так и не ответил, что ты собрался делать с метками функций с panic из стандартной библиотеки?

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Расскажи мне про ручное управление памятью в Rust.

https://doc.rust-lang.org/1.15.0/alloc/heap/fn.allocate.html

Судя по тому, что аргументы у тебя закончились и ты банально перешёл на личности

После тебя

я таки прав

Ты только считаешь, что прав.

ты так и не ответил, что ты собрался делать с метками функций с panic из стандартной библиотеки?

tailgunner> В местах, где паника недопустима, будет использоваться не foo, а foo.get(i).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 4)
Ответ на: комментарий от bbk123

При том, что там тоже автоматическое управление памятью.
тоже

У Rust не автоматическое.

В drop нельзя вручную управлять памятью, это же очевидно.

С чего бы это вдруг? А Arc/Rc по вашему как работают?

RazrFalcon ★★★★★
()
Ответ на: комментарий от tailgunner

Расскажи мне про ручное управление памятью в Rust.

https://doc.rust-lang.org/1.15.0/alloc/heap/fn.allocate.html

Ну и какое отношение это имеет к drop? Ты бы ещё new в Java ручным управлением памяти назвал.

После тебя Ты только считаешь, что прав.

Значит что делать с твоими метками функций с panic ты так и не расскажешь? А я так ждал, мне было так интересно.

bbk123 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.