ਰਸਟ 1.96 ਰੀਲੀਜ਼: ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਫਰਮਵੇਅਰ ਵਿਕਾਸ ਲਈ ਰਸਟ ਦੀ ਅਨੁਕੂਲਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ

ਰਸਟ 1.96 ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ, ਜੋ ਮੋਜ਼ੀਲਾ ਪ੍ਰੋਜੈਕਟ ਦੁਆਰਾ ਸਥਾਪਿਤ ਕੀਤੀ ਗਈ ਸੀ ਪਰ ਹੁਣ ਸੁਤੰਤਰ ਗੈਰ-ਮੁਨਾਫ਼ਾ ਰਸਟ ਫਾਊਂਡੇਸ਼ਨ ਦੀ ਸਰਪ੍ਰਸਤੀ ਹੇਠ ਵਿਕਸਤ ਕੀਤੀ ਗਈ ਹੈ, ਜਾਰੀ ਕੀਤੀ ਗਈ ਹੈ। ਇਹ ਭਾਸ਼ਾ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ ਅਤੇ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਅਤੇ ਰਨਟਾਈਮ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਦੇ ਉੱਚ ਸਮਾਨਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਾਧਨ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ (ਰਨਟਾਈਮ ਨੂੰ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਮੁੱਢਲੇ ਸ਼ੁਰੂਆਤੀਕਰਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ)।

ਰਸਟ ਦੇ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਢੰਗ ਪੁਆਇੰਟਰ ਹੇਰਾਫੇਰੀ ਵਿੱਚ ਗਲਤੀਆਂ ਨੂੰ ਖਤਮ ਕਰਨ ਅਤੇ ਘੱਟ-ਪੱਧਰੀ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਮੁੱਦਿਆਂ ਤੋਂ ਬਚਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, ਜਿਵੇਂ ਕਿ ਮੈਮੋਰੀ ਨੂੰ ਖਾਲੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਐਕਸੈਸ ਕਰਨਾ, ਨਲ ਪੁਆਇੰਟਰਾਂ ਨੂੰ ਡੀਰੇਫਰੈਂਸ ਕਰਨਾ, ਬਫਰ ਓਵਰਰਨ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਹੋਰ। ਪ੍ਰੋਜੈਕਟ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਵੰਡਣ, ਬਿਲਡਾਂ ਦੀ ਸਹੂਲਤ ਦੇਣ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਕਾਰਗੋ ਪੈਕੇਜ ਮੈਨੇਜਰ ਵਿਕਸਤ ਕਰ ਰਿਹਾ ਹੈ। crates.io ਰਿਪੋਜ਼ਟਰੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਲਈ ਬਣਾਈ ਰੱਖੀ ਜਾਂਦੀ ਹੈ।

ਰੈਫਰੈਂਸ ਚੈਕਿੰਗ, ਆਬਜੈਕਟ ਦੀ ਮਲਕੀਅਤ ਦਾ ਟ੍ਰੈਕ ਰੱਖਣ, ਆਬਜੈਕਟ ਲਾਈਫਟਾਈਮ (ਸਕੋਪਾਂ) ਦਾ ਟ੍ਰੈਕ ਰੱਖਣ ਅਤੇ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੌਰਾਨ ਮੈਮੋਰੀ ਐਕਸੈਸ ਦੀ ਸ਼ੁੱਧਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦੁਆਰਾ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਰਸਟ ਵਿੱਚ ਕੰਪਾਈਲ ਸਮੇਂ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੰਗਾਲ ਪੂਰਨ ਅੰਕ ਓਵਰਫਲੋ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਵੇਰੀਏਬਲ ਮੁੱਲਾਂ ਦੀ ਲਾਜ਼ਮੀ ਸ਼ੁਰੂਆਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਗਲਤੀਆਂ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਟੱਲ ਸੰਦਰਭਾਂ ਅਤੇ ਵੇਰੀਏਬਲਾਂ ਦੀ ਧਾਰਨਾ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਲਾਜ਼ੀਕਲ ਗਲਤੀਆਂ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਮਜ਼ਬੂਤ ​​ਸਥਿਰ ਟਾਈਪਿੰਗ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।

ਮੁੱਖ ਨਵੀਨਤਾਵਾਂ:

• Добавлен модуль range с реализацией новых типов, развиваемых для замены устаревших типов Range, RangeInclusive, RangeToInclusive и RangeFrom, и позволяющих хранить диапазоны в Copy-структурах. Тип Range определяет диапазоны, ограниченные минимальным и максимальным допустимым значением (но не входящим в него), тип RangeFrom определяет числа начиная с указанного значения, а тип RangeInclusive — значения указанного диапазона с обеими его границами. В будущих выпусках дополнительно появятся типы RangeFull и RangeTo, старая реализация будет перенесена в core::range::legacy::*, а синтаксис «N..M» переведут на новый вариант типов.

  Новые типы отличаются тем, что вместо типажа Iterator реализуют типаж IntoIterator, т.е. вместо встроенного итератора определяют то, как преобразовать тип в итератор. Подобный подход позволяет использовать с новыми типами операцию копирования (типаж Copy, показывающий, что значения типа можно дублировать через простое копирование), которая ранее была недоступна из-за несовместимости с типами со встроенными итераторами.
  Например, новые типы дают возможность сохранить границы среза в структуру, которая полностью копируется без раздельного сохранения начального и конечного значений:

  use core::range::Range;

  #[derive(Clone, Copy)]
  pub struct Span(Range<usize>);

  impl Span {
  pub fn of(self, s: &str) -> &str {
  &s[self.0]
  }
  }

• Добавлены макросы «assert_matches!» и «debug_assert_matches!», проверяющие соответствие значения указанному шаблону и аварийно завершающие выполнение при расхождении. От выражений «assert!(matches!(..))» и «debug_assert!(matches!(..))» новые макросы отличаются выводом отладочной информации со значениями, вызвавшими сбой. Для избежания пересечений со сторонними макросами, поставляемыми с аналогичными именами, новые макросы требую явного импорта библиотеки «core::assert_matches».

  use core::assert_matches;

  fn get_random_number() -> u32 {
  4
  }

  fn main() {
  assert_matches!(get_random_number(), 1..=6);
  }

• При сборке для целевой платформы WebAssembly прекращена передача компоновщику опции «—allow-undefined», разрешавшей связывание при наличии неопределённых символов, которые преобразовывались в импорт из модуля «env». При сборке для WebAssembly все связанные с компоновкой символы теперь по умолчанию обязательно должны быть определены. Для возвращения старого поведения можно использовать переменную окружения «RUSTFLAGS=-Clink-arg=—allow-undefined» или выражение ‘#[link(wasm_import_module = «env»)]» в коде.
• API ਦੇ ਇੱਕ ਨਵੇਂ ਹਿੱਸੇ ਨੂੰ ਸਥਿਰ ਦੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਭੇਜਿਆ ਗਿਆ ਹੈ, ਜਿਸ ਵਿੱਚ ਗੁਣਾਂ ਦੇ ਤਰੀਕਿਆਂ ਅਤੇ ਲਾਗੂਕਰਨ ਨੂੰ ਸਥਿਰ ਕੀਤਾ ਗਿਆ ਹੈ:
  • assert_matches!
  • debug_assert_matches!
  • From<T> for AssertUnwindSafe<T>
  • From<T> for LazyCell<T, F>
  • From<T> for LazyLock<T, F>
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter
• В пакетном менеджере Cargo устранена уязвимость CVE-2026-5223, которая может использоваться для перезаписи исходного кода другого crate-пакета в локальном кэше пакетов из того же репозитория через манипуляции с символическими ссылками внутри crate-а пакетов. Уязвимость проявляется только при работе со сторонними репозиториями пакетов и не затрагивает пользователей репозитория crates.io, так как в crates.io запрещена загрузка пакетов с символическими ссылками.

Дополнительно можно отметить публикацию (PDF) результатов анализа пригодности языка Rust для разработки прошивок для микроконтроллеров и встраиваемых систем с ограниченными ресурсами.
Исследование проведено компанией STMicroelectronics при участии нескольких европейских университетов. Двум изолированным командам разработчиков была поставлена задача по реализации одной и той же прошивки для микроконтроллеров STM32U585AI с ядром Arm Cortex-M33. Первая команда создавала прошивку на Си, а вторая на Rust.

Тестирование выполненной работы не выявило заметных преимуществ в использовании языка Си вместо Rust при разработке прошивок для микроконтроллеров при сравнении потребления памяти и производительности. Более того, задействование написанного на Rust системного runtime от открытого проекта Ariel OS позволило добиться потребления памяти в проекте на Rust ниже, чем в реализации на языке Си, использующей традиционный стек для разработки прошивок на базе библиотеки newlib.

Размер результирующей прошивки составил 84100 байт в проекте на Rust и 76744 байта в проекте на Си (на 10% меньше), но потребление оперативной памяти в прошивке на Rust оказалось значительно ниже — 24640 байтов против 42608 байтов. Что касается производительности, то при тестировании начальных прототипов, разработанных за 6 недель, реализация на Rust в два раза опережала, реализацию на Си, но обе реализации значительно отставали от расчётной максимальной производительности. После 4 недель, выделенных на оптимизацию, обе реализации достигли примерно одинакового результата, близкого к расчётному максимуму.

ਸਰੋਤ: opennet.ru