LINUX.ORG.RU

Rust 1.91.0

 ,


0

4

Представлена новая версия языка программирования Rust. Rust – язык программирования общего назначения, который освобождает программиста от ручного управления памятью благодаря механизму владения, без использования сборщика мусора.

Список изменений:

  • aarch64-pc-windows-msvc теперь является платфомой первого уровня поддержки (ранее было второго уровня). По сравнению со вторым уровнем поддержки, первый уровень подразумевает обязательное успешное прохождения всех тестовых наборов на платформе.

  • Добавлена проверка линтера при возвращении из функции «висячего» указателя. Встроенный в компилятор Borrow Checker уже имеет проверку на тот случай, когда возвращается «висячая» ссылка, но это не работало при использовании сырых указателей. Теперь будет сгенерировано предупреждение:

fn f() -> *const u8 {
    let x = 0;
    &x
}
warning: a dangling pointer will be produced because the local variable `x` will be dropped
 --> src/lib.rs:3:5
  |
1 | fn f() -> *const u8 {
  |           --------- return type of the function is `*const u8`
2 |     let x = 0;
  |         - `x` is part the function and will be dropped at the end of the function
3 |     &x
  |     ^^
  |
  = note: pointers do not have a lifetime; after returning, the `u8` will be deallocated
    at the end of the function because nothing is referencing it as far as the type system is
    concerned
  = note: `#[warn(dangling_pointers_from_locals)]` on by default

В разряд стабильного API было переведено:

  • Path::file_prefix
  • AtomicPtr::fetch_ptr_add
  • AtomicPtr::fetch_ptr_sub
  • AtomicPtr::fetch_byte_add
  • AtomicPtr::fetch_byte_sub
  • AtomicPtr::fetch_or
  • AtomicPtr::fetch_and
  • AtomicPtr::fetch_xor
  • {integer}::strict_add
  • {integer}::strict_sub
  • {integer}::strict_mul
  • {integer}::strict_div
  • {integer}::strict_div_euclid
  • {integer}::strict_rem
  • {integer}::strict_rem_euclid
  • {integer}::strict_neg
  • {integer}::strict_shl
  • {integer}::strict_shr
  • {integer}::strict_pow
  • i{N}::strict_add_unsigned
  • i{N}::strict_sub_unsigned
  • i{N}::strict_abs
  • u{N}::strict_add_signed
  • u{N}::strict_sub_signed
  • PanicHookInfo::payload_as_str
  • core::iter::chain
  • u{N}::checked_signed_diff
  • core::array::repeat
  • PathBuf::add_extension
  • PathBuf::with_added_extension
  • Duration::from_mins
  • Duration::from_hours
  • impl PartialEq<str> for PathBuf
  • impl PartialEq<String> for PathBuf
  • impl PartialEq<str> for Path
  • impl PartialEq<String> for Path
  • impl PartialEq<PathBuf> for String
  • impl PartialEq<Path> for String
  • impl PartialEq<PathBuf> for str
  • impl PartialEq<Path> for str
  • Ipv4Addr::from_octets
  • Ipv6Addr::from_octets
  • Ipv6Addr::from_segments
  • impl<T> Default for Pin<Box<T>> where Box<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Rc<T>> where Rc<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Arc<T>> where Arc<T>: Default, T: ?Sized
  • Cell::as_array_of_cells
  • u{N}::carrying_add
  • u{N}::borrowing_sub
  • u{N}::carrying_mul
  • u{N}::carrying_mul_add
  • BTreeMap::extract_if
  • BTreeSet::extract_if
  • impl Debug for windows::ffi::EncodeWide<'_>
  • str::ceil_char_boundary
  • str::floor_char_boundary
  • impl Sum for Saturating<u{N}>
  • impl Sum<&Self> for Saturating<u{N}>
  • impl Product for Saturating<u{N}>
  • impl Product<&Self> for Saturating<u{N}>

Признак const добавлен к следующим функциям:

  • <[T; N]>::each_ref
  • <[T; N]>::each_mut
  • OsString::new
  • PathBuf::new
  • TypeId::of
  • ptr::with_exposed_provenance
  • ptr::with_exposed_provenance_mut

>>> Подробнее

★★★

Проверено: hobbit ()
Последнее исправление: Wizard_ (всего исправлений: 2)
Ответ на: комментарий от tinykey

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

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

Я не про то, что на Си++ нельзя написать безопасный код. Я про то, что очень легко написать код, который выглядит как нормальный, но делает UB.

При этом, так как это UB, то нет даже гарантии, что он аварийно завершиться, он может делать что угодно.

https://godbolt.org/z/hsqdbE6Eq

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

Я ничего не имею против haskell, но ты же не будешь спорить, что это нишевый язык?

С чего это? Нормальный язык общего назначения. Не более нишевый, чем Java, например.

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

Задумайся, почему бы на рже в основном только переписывают готовое?

Потому же, почему в Linux переписывают уже было готовое в других ОС. Потому что это готовое тоже надо переписать, а готового больше, чем нового.

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

Видимо, мы немного по разному понимаем нишевость. ;) Ну, кто-то и doom пишет в excel, вольному воля… Пойми правильно, haskell замечательный язык, и гарантии по поводу memory safety он дает ничуть не худшие, чем rust, и делает это гораздо честнее – вводит свои правила игры, не мимикрируя под ООП-язык, в чисто функциональной парадигме. Но в продакшне таки куда более используется java и python, нежели haskell.

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

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

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

Постулировалось что из-за ограничений программировать гуи нельзя. Оказалось можно, да так можно, что всем понравилось и они уже второе из основных (просмотрщик документов) приложение на расте написали. И матричный клиент вроде бы тоже.

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

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

Но в продакшне таки куда более используется java и python, нежели haskell.

Это вопрос популярности и моды. PL/1 тоже нишевый язык?

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

Пример, который ты привел, не UB начиная с C++23

А это вообще прекрасно. Теперь на C++ есть корректный код, который на старой версии компилируется без предупреждений, но является UB. То есть его обязательно надо заворачивать в проверку значения __cplusplus.

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

А это вообще прекрасно. Теперь на C++ есть корректный код, который на старой версии компилируется без предупреждений, но является UB. То есть его обязательно надо заворачивать в проверку значения __cplusplus.

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

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

Ну да, ну да, просто все рвутся наперегонки. Загляни-ка в свежую темку: https://www.opennet.ru/opennews/art.shtml?num=64214 , зацени исправленные ошибки, подумай сколько их еще осталось… Падение с переполнением стека – вообще шедевр.

Ладно, ты прав, спорить с сектантами – никогда не стоит потраченного времени. Удачи!

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

Загляни-ка в свежую темку: https://www.opennet.ru/opennews/art.shtml?num=64214 , зацени исправленные ошибки, подумай сколько их еще осталось

Там недоделанные программы, которыми пытались заменить coreutils. Та же история была последние 20 лет между BSD и Linux. Язык тут вообще не при чем.

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

который на старой версии компилируется без предупреждений

Код, написанный под новый стандарт, в режиме старого вообще не компилируется. // К.О.

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

Или может оказаться, что std::unique_ptr в шаблоне от неполного класса тоже UB. Надо стандарт смотреть, кто прав.

monk ★★★★★
()
Ответ на: комментарий от rmammoth
const std::vector<int> &v() const &

выглядит как костыль. впрочем пример ошибки в языке хороший, рабочий.

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

им бы стоило не убивать временные объекты «как только так сразу» а лишь на выходе из конструкции.

for (auto x : make_smth().v()) {
   std::print("{}", x);
} //вот тута!
ckotctvo
()
Ответ на: комментарий от monk

Всё правильно ругается Clang. cmGlobalGenerator объявлен, но не определен, и когда в 56 строке возвращается unique_ptr на него, там вторым параметром шаблона – умолчальный deleter. Про cmGlobalGenerator вообще не известно, что у него с деструктором – а вдруг он запрещен? У шланга, видимо, более строгая проверка.

А вообще, код изначально неровный: я бы cmGlobalGeneratorFactory сделал шаблонным классом, параметризуемым типом базового класса генерируемой иерархии. Тогда не нужно было бы предобъявлять cmGlobalGenerator, а фабрика могла бы использоваться не только для генераторов при необходимости.

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

для этого надо заковычку ставить. а можно без заковычки если четко определить что содержимое for (…) живет весь цикл.

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

алсо, я не уверен что эта заковычка спасает говнокод.

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

https://en.cppreference.com/w/cpp/language/range-for.html

Я не попугай – повторять одно и то же. Просвещайся. Заковычка, кстати, называется амперсанд, и в C++23 он не нужен.

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

Кстати, в контексте того, что вроде как стандарты сверху вниз совместимы. Почему во всех современных компиляторах без -std= используется C++14? Есть какая-то причина?

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

ОК. В msvc c++14 (а __cplusplus вообще 199711), в clang/gcc с++17. Но всё равно даже не 20. Почему?

Когда-то при первых стандартах вроде наоборот было: по умолчанию последняя версия, а всякими ansi/c89 можно было старую поставить.

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

Тут я могу только догадываться. М.б. дают время на стабилизацию и обкатку фич. А м.б. что-то из следующих стандартов еще не реализовано полностью, кажется, с модулями не все гладко.

P.S. Да, не все еще запилили: https://en.cppreference.com/w/cpp/compiler_support/23.html

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

Я про разработку, а не про HelloWorld.cpp. Любой проект фиксирует стандарт, и в дальнейшем его только повышает. Совместимость работает только в одну сторону. Какие-то азбучные вещи, не?

Ну то есть, в каком сценарии по-твоему понадобится это #if __cplusplus?

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

Ну ноги всяким бракоделам ломает и руки и голову и ещё задницу наверное. Потому что очень странно что его не ввели сразу прямо в начале с++

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

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

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

Я хочу быть уверенным что код сработает так как я задумал. Без танцев с бубном.

Компилируй с -O0 и логика компилятора будет достаточно прямолинейной.

Впрочем, на современных процессорах это всё равно может не спасти, ведь OoO (перестановка операций) есть.

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

Компилируй с -O0 и логика компилятора будет достаточно прямолинейной.

Начиная с C++17, copy elision будет применяться в оговоренных стандартом случаях даже при компиляции с -O0. Правильное решение проблемы – не полагаться на сторонние эффекты в конструкторах копирования / перемещения, что, собственно, вполне логично.

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

Я не хочу писать осторожно Я хочу быть уверенным что код сработает так как я задумал.

Задумывай в соответствии со стандартом языка, и все будет правильно.

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

Я не хочу писать осторожно Я хочу быть уверенным что код сработает так как я задумал.

Тем удивительнее, что тебе не нравится раст.

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

Тем удивительнее, что тебе не нравится раст.

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

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

Проблема не в том, что Haskell это нишевый язык, а в том, что его ниша - это написание статей с закосом под академические про опердени, а не написание кода. А то, что на нем и написано сделано скорее вопреки, чем благодаря.

Minoru ★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.