LINUX.ORG.RU

Rust 1.91.0

 ,


0

5

Представлена новая версия языка программирования 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)
Ответ на: комментарий от Darfin

Боров чеккер работает в компайл тайме

Да не работает же глобально. Иначе бы тот же refcell не понадобился. Чуть асинхронности и многопоточности и он складывает свои полномочия. Буквально там, где он как бы должен решать проблемы.

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

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

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

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

И что теперь, для каждого объекта писать обёртку? Даже в примере из этого топика, обернуть инт, написать обёртку для оператора += (а в общем случае - для всех операторов), и это всё только для того, чтобы избежать явного лока мутекса?

unC0Rr ★★★★★
()

Сишники продолжают демонстрировать упёртое дугоумие. RefCell, как и другие смарт пойнтеры в расте, не противоречат броу-чекеру, а наоборот нужны для того, чтоб удовлетворить его в специфических юзкейсах. Например, если хочется менять свойства немутабельной структуры, придумали RefCell и включили в стандартную библиотеку, чтоб вам не нужно было изобретать велосипед каждый раз. Да, есть высокоуровневые языки, в которых смарт пойнтеры не нужны, но в них вместо этого есть сборщик мусора, который не всех устраивает. А сей это всё не касается, потому что строгих правил владения нет, и безопасное выделение памяти в компайл тайм не гарантируется.

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

RefCell и многопоток были в разных предложениях.

Но мне понравилось твоё признание, что боров даже в однопотоке не может проверить корректность кода и нужно runtime-костыли добавлять.

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

RefCell и многопоток были в разных предложениях.

А поводу чего ещё ты ноешь? Я возможно пропустил.

Но мне понравилось твоё признание, что боров даже в однопотоке не может проверить корректность кода и нужно runtime-костыли добавлять.

Страдание неизбежно, вопрос исключительно в его количестве.

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

если хочется менять свойства немутабельной структуры

Ахах. А почему она тогда немутабельная, если её нужно менять? В этом весь раст. Сначала напердодили себе сложностей, а потом изобрели костыли, чтобы распердолить обратно.

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

Тогда мне кинуть им pull request на удаление refcell из stdlib или сам сделаешь?

Сделай конечно, мы с удовольствием понаблюдаем за вашей дискуссией.

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

Ты бы лучше писал на расте

Возросший уровень пердолинга не компенсируется преимуществами, которые рекламируются(во многом брехливо) растом.

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

Но мне понравилось твоё признание, что боров даже в однопотоке не может проверить корректность кода и нужно runtime-костыли добавлять.

Дурилка, боров гарантирует корректное выделение/освобождение памяти, а не «корректность кода». Это разные вещи.

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

Ну вот ты уже торгуешься, потому что понимаешь, что идея тупая была. А если тебе не прибавлять 1 надо будет, а умножать на 3 и делить 2, чем тебе атомики помогут? И что ты вообще будешь делать, два раза брать мутекс, для умножения, потом деления, или напишешь отдельный метод сразу для обеих операций?

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

А почему она тогда немутабельная, если её нужно менять? В этом весь раст.

Дурилка, в немутабельных структурах могут быть мутабельные свойства. Это валидный паттерн не только в расте, ты об этом не знал?

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

Сделай конечно, мы с удовольствием понаблюдаем за вашей дискуссией.

Хочешь сказать, что тебя засрут свои же растовчане за фразу «Видишь, и RefCell уже не нужен». А зачем ты тогда мне такое писал?

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

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

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

Угу, а потом ещё завернуть в цикл на случай, если значение поменялось, пока операции проводились. Напоминаю, обсуждаем простую в использовании альтернативу методу .lock()

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

Хочешь сказать, что тебя засрут свои же растовчане за фразу «Видишь, и RefCell уже не нужен».

Нет, не хочу, откуда ты это вообще взял?

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

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

Так в этом и смысл atomic_cmpxchg.

Напоминаю, обсуждаем простую в использовании альтернативу методу .lock()

Атомик не отправлят программу спать.

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

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

Если боров гарантирует, то зачем в расте есть arc/rc? Их добавили туда просто так и ими никто не пользуется? Но на примере того же tokio, который весь обмазан Rc, видим что заявления «боров гарантирует» брехня.

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

Если боров гарантирует, то зачем в расте есть arc/rc? Их добавили туда просто так и ими никто не пользуется? Но на примере того же tokio, который весь обмазан Rc, видим что заявления «боров гарантирует» брехня.

Боров гарантирует что ты правильно пользуешься Arc/Rc, очевидно же.

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

Не нужно мне рекламировать атомики, мы тут обсуждаем предложение вместо Mutex писать MutexedStruct с реимплементацией всех методов, уже внутри которых берётся мутекс.

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

RefCell не нужен это не мои слова )

Ты их явно энтерпретировал неправильно, но не суть.

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

Если боров гарантирует, то зачем в расте есть arc/rc?

Чтобы удовлетворить правилам борова, йопта! Иначе твоя программа не скомпилируется. У тебя внатуре си весь мозг выел штоле?

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

А как можно неправильно счётчик ссылок использовать? Сразу скажу, что для циклических ссылок есть weak_ptr.

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

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

Остальные это кто? Ищем «Interior Mutability» в любимом чатботе, и перестаём кочить из себя клоуна.

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

Чтобы удовлетворить правилам борова, йопта!

В нормальных языках счётчик ссылок нужен, чтобы определить момент удаления объекта. И только в раст он нужен, чтобы удовлетворять борова. Бгг. Зачем вы себе сложности придумываете?

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

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

«Interior Mutability»

По-русски это называется говнокод с костылями.

любимом чатботе

Копипаста чатбота это вторичный продукт.

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

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

А может он тебе ещё кунилингус должен сделать? Боров-чекер в расте это три простых правила, которые гарантируют (подчёркиваю гарантируют) отсутствие висящих ссылок и дата рейсов и проверяются в компайл тайм. Чтоб этим правилам удовлетворить, нужно часто писать определённые паттерны, которые в итоге вынесены в stdlib, чтоб сэкономить несколько строк бойлерплейта там и сям. Это нормальный подход, который используется во всех нормальных япах.

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

По-русски это называется говнокод с костылями.

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

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

Реф не взять, значение использовать.

Ничё не понял. Вот в цпп, если у меня на руках есть объект shared_ptr, то это гарантирует, что данные в нём не удалены. Зачем тут нужен боров и от чего он защищает?

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

Ничё не понял. Вот в цпп, если у меня на руках есть объект shared_ptr, то это гарантирует, что данные в нём не удалены

#include <memory>
#include <print>

int main() {
	int *rawp;
	{
		std::shared_ptr<int> p = std::make_shared<int>(0);
		rawp = p.get();
	}
	std::print("{}\n", *rawp);
}

Бабах.

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

Зачем ты вынул и сохранил сырой указатель? Я же сказал, что у меня на руках shared_ptr. Используй его всегда и передавай по значению.

Давай я тебе в ответ пришлю портянку на раст с unsafe и буду пытаться этим что-то доказать.

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

Зачем ты вынул и сохранил сырой указатель?

Потому что могу и компилятор меня от этого не остановил.

Я же сказал, что у меня на руках shared_ptr. Используй его всегда и передавай по значению.

Пишите без багов, а с багами – не пишите.

Давай я тебе в ответ пришлю портянку на раст с unsafe и буду пытаться этим что-то доказать.

Весь смысл borrow checker’а – понизить риски memory corruption багов, коими славятся C и C++. Для этого надо либо GC делать, либо маниакально контролировать куда ты с указателями ходишь. На этом примере мы убедились почему это полезно и от каких именно страданий нас спасает.

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

Потому что могу и компилятор меня от этого не остановил.

А почему он должен был? Почему компилятор должен считать пользователя за дурака? Сырой указатель доставать из shared_ptr иногда нужно

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

Сырой указатель доставать из shared_ptr иногда нужно

Так и замечательно. Но вот когда ты его достал - полномочия компилятора цпп всё, а раст автоматически проследит, чтобы ты корректно пользовался достанным.

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

А почему он должен был? Почему компилятор должен считать пользователя за дурака? Сырой указатель доставать из shared_ptr иногда нужно

Все так. А потом рефакторинг, ссылку дропнули раньше, ноги разъехались, RCE.

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

Почему компилятор должен считать пользователя за дурака?

Потому что это так и есть. Об этом говорит статистика багов.

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

риски memory corruption багов, коими славятся C и C++

Этим славится только си. Современный C++ позволяет писать безопасный код, если ты не шиз вроде Столярова, который до сих пор пишет на си с классами.

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

Я в расте могу unsafe написать. Дальше что?

Можешь. Дальше правила кодирования, внимательное code review unsafe {} секций и старательное сведение их к минимуму.

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