LINUX.ORG.RU

Rust 1.49

 


2

5

Опубликован релиз 1.49 языка программирования Rust.

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

Чтобы чётко обозначить, насколько поддерживается каждая система, используется система уровней:

  • Уровень 3. Система поддерживается компилятором, но не предоставляются готовые сборки компилятора и не прогоняются тесты.

  • Уровень 2. Предоставляются готовые сборки компилятора, но не прогоняются тесты

  • Уровень 1. Предоставляются готовые сборки компилятора и проходят все тесты.

Список платформ и уровней поддержки: https://doc.rust-lang.org/stable/rustc/platform-support.html

Новое в релизе 1.49

  • Поддержка 64-bit ARM Linux переведена на уровень 1 (первая система, отличная от систем на x86, получившая поддержку уровня 1)

  • Поддержка 64-bit ARM macOS переведена на уровень 2.

  • Поддержка 64-bit ARM Windows переведена на уровень 2.

  • Добавлена поддержка MIPS32r2 на уровне 3. (используется для микроконтроллеров PIC32)

  • Встроенный тестовый фреймворк теперь выводит консольный вывод, сделанный в другом потоке.

  • Перенесены из Nightly в Stable три функции стандартной библиотеки:

  • Две функции теперь помечены const (доступны на этапе компиляции):

  • Повышены требования к минимальной версии LLVM, теперь это LLVM9 (было LLVM8)

>>> Подробности

★★★★

Проверено: Shaman007 ()

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

Поверь мне, аноним, в твоём сообщении нет ни одного утверждения, которое не было бы идиотским. Это просто чудо, сложно написать чушь от первого до последнего слова, но ты смог. Чтоб не тратить время, беру самое первое:

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

Разбором выражения занимаюсь именно я. Собственно поэтому и описывают «правило право-лево», чтоб люди, читающие исходник, смогли понять что там написано. Для разработчиков компиляторов существуют другие книги/статьи, по теории формальных языков, например.

khrundel ★★ ()

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

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

Бесполезный мусор, как и всё в C++. Никто не запрещает передать туда кривой указатель.

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

Никто не запрещает прибавить 2 вместо 3 в расте. Подгорать.

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

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

Я привел тебе и твоему прихлебале схожие уродства синтаксиса rust, на которые вынуждены идти его создатели. rust - c++ в новом фантике, не более.

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

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

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

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

все компоненты определены однозначно

Однозначно определены значения версий, но не само содержимое (исходники, бинарники и прочие блобы).

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

будет вызван std::terminate

Зсб решение.

auto p = new int(1);
gsl::not_null<int*> test = p;
delete p;

ok

uintptr_t i = 10;
gsl::not_null<int*> test = (int*)i;

ok

Ну и толку от него? Это фундаментальный баг уровня std::optional dereferncing.

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

cargo сверяет хеши.

Ты указываешь хеши в описании пакетов? Откуда карга достанет то, чего нет?

Кстати, на заметку, хеш - неоднозначная функция. И для «однозначности» хешировать надо не только исходники, но и саму сборку.

anonymous ()

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

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

хеш - неоднозначная функция

на всякий случай: под «однозначностью» в моем посте, конечно, не имелась в виду математическая однозначность, т.е. случай существования двух разных версий исходника (или разных версий множества файлов исходников) с одним и тем же значением хеша априори исключается

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

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

Скорость компиляции конечно же зависит как от сложности синтаксиса и семантики языка, так и от заложенных возможностей инкрементальной разработки. В С++ со всем этим плохо. «Нет проблем» только на хеллоуворлдах, в больших проектах приходится идти на прогулку на время ребилда.

выучи язык и пиши правильно и все у тебя будет работать

Выучить можно все, что угодно. Люди даже на бейсике писали (и пишут) продашн код, и на асме графический интерфейс, сайты и объектную систему - надо ли так делать? Нет. Вот то же самое и с С++. Я тебя ни к чему не призываю, самому лет 15 назад нравилось на плюсах писать, просто объективные факты не в пользу него (помимо нескольких весьма узких ниш, и то в основном по причинам уже написанных библиотек и компиляторов).

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

ORLY?

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

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

самые крутые штуки пишутся именно на сях

Кроме игр я ядра в парочке ос, что там еще такого крутого пишется? Числодробилка известных алгоритмов? О да, очень круто (в скобочках - нет).

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

И сразу придет к выводам, что срочно надо фиксить меморилики. Но где и как... ?!

посмотри на синтаксис раста https://doc.rust-lang.org/stable/rust-by-example/conversion/try_from_try_into... и скажи что тебе понятнее, си или вот это вот что по ссылке.

Rust почти не знаю, но по ссылке достаточно симпатичный кусок кода, очевидный и понятный.

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

Однозначно определены значения версий, но не само содержимое

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

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

Нет, это не проблемы «системы контроля версий и методики ее использования». Никак ты по libversion := [6.4; 7.0) не сможешь воспроизводимо собирать.

версии в VCS

Причём здесь vcs? Речь про сборку. Нет там никакой vcs.

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

Никак ты по libversion := [6.4; 7.0)

если процесс сборки/пакетирования и версионирования libversion детерминирован, то не должно быть проблем

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

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

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

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

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

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

Нет, естественно ни о каком парсере я не говорил, то, что ты додумал идиотское - это говорит о тебе. Я написал об уродском синтаксисе языка C, о том, как разбор объявления типа приходится делать по довольно сложному алгоритму и эта сложность не обусловлена ничем рациональным. А будет это делать компилятор или человек-читатель - этого вопроса я вообще не касался.

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

А как в таком случае цеплять библиотеки с хоста?

Не знаю. С crates.io работает…

The purpose of a Cargo.lock is to describe the state of the world at the time of a successful build. It is then used to provide deterministic builds across whatever machine is building the package by ensuring that the exact same dependencies are being compiled.
fsb4000 ★★★★ ()
Ответ на: комментарий от alienclaster

самому лет 15 назад нравилось на плюсах писать

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

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

самому лет 15 назад нравилось на плюсах писать

это в школьном кружке чтоли?

В универе и на первой работе (делал очень веселые штуки в сове время - в том числе писал генераторы для vhdl на плюсах / прочую цифровую схемотехнику и генераторы html для бизнеса), в школе я писал на паскале и бейсике и php.

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

Попробуй доказать?

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

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

Либо из тебя хреновый мейнтейнер, либо ты просто жиробасик. В Gentoo же смогли сделать, что бы Rust проекты собирались со включённым network-sandbox (Т.е. без сети). И в Debian смогли. И вообще, ты можешь собственный реестр/репозиторий крейтов сделать.

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

А GCC или Clang ты можешь собрать из исходников без «блоба» - уже скомпилированного GCC или Clang? Нет? Всё, GCC и Clang для тебя - больше тоже не опенсорс.

Собственно это легко объясняется чтением растового багтрекера. Складывается ощущение, что авторы уже давно сами запутались что они лепят. И особенно доставляет, как часто они не могут что-то починить, потому что это дурацкий LLVM во всём виноват.

LLVM не дурацкий, но он действительно «виноват». Правда, какое это отношение имеет к опакечиванию?

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

Очередная глупость.

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

А GCC или Clang ты можешь собрать из исходников без «блоба» - уже скомпилированного GCC или Clang? Нет? Всё, GCC и Clang для тебя - больше тоже не опенсорс.

«Блоб» это то что без исходиков?

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

C++ компилируется довольно быстро. По крайней мере точно быстрее чем:

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

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

C++ компилируется довольно быстро. По крайней мере точно быстрее чем:

Ваши комментарии всегда очень остроумные. Могу дать совет как дискредитировать rust ещё сильнее, в следующий пишите всё тоже самое только как бы от лица фаната rust.

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

В данном случае «блобом» он назвал либо официальный бинарик rustc, либо rustup. Но и rustc, и rustup имеют открытые исходники под двойной лицензией Apache 2.0 / MIT. И прекрасно собираются из них на Gentoo, в частности.

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

Откуда дровишки?

Из личного опыта.

разница в скорости компиляции была кратной.

Код на плюсах был плох с точки зрения скорости компиляции.

Использовались ли модули или хотя бы предкомпилированные заголовки?

Контролировались ли специализации шаблонов? Лишние специализации не должны создаваться, и компилироваться одна специализация должна максимум один раз, а не в каждом файле.

Использовались ли предварительное объявление там где можно обойтись им вместо include?

Если ответ на всё да, то я не верю, что плюсы компилировались медленнее раста.

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

А GCC или Clang ты можешь собрать из исходников без «блоба» - уже скомпилированного GCC или Clang? Нет?

да!

stage0

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

Это фундаментальный баг уровня std::optional dereferncing.

А что там?

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

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

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

Я даже специально выделил «ты» в своём сообщении. Понятное дело, что так можно, с Rust - тоже. Тык. Тык. Просто анончик не стал заморачиваться и решил уныленько набросить. Да, этот компилятор (mrustc) начал пилиться позже, изначально rustc собирался как-то иначе. Но я почти уверен, что эксгумировать окаменевшую версию, которая написана на OCaml - можно, однако никому нафиг не нужно кроме парочки хикканов с параноидальной шизофренией.

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

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

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

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

Ага «для меня» и «выглядит».

А я вот сформулирую утверждение, которое гораздо сильнее: синтаксис C не «для меня», а объективно и не «выглядит», а является уродским. И могу даже это доказать. Набираешь в гугле «правило право-лево» и где-то на первой странице встречаешь объяснение, как разбирать сложные объявления указателей. Это не вопрос каких-то соглашений для нормальной работы сложных систем, поддерживаемых десятилетиями коллективами из сотни программистов, нет, это сраный парсинг типа переменной! А всё почему? Потому что в одном из первых структурных языков алголе решили поместить тип переменных слева от имени. Решение основанное не на чём. А потом в сях (или в каком-то промежуточном языке) решили объявлять массивы скобками после имени, а под конец попытались обобщить правило объявления так, чтоб оно покрывало объяление функций, переменных и массивов. С тех пор наследники алгола и C занимаются тем, что выбирают насколько упростить объявления. Те, кто посмелее (обычно теоретики) просто делают сразу нормально. Те, кто пытается не пугать старых программистов, оставляют тип слева, но от порнографии с описанием типа, который окружает идентификатор, отказались все. Одно только объявление функции осталось в виде исключения.

Ну что враль мелкая, все еще ничего не говорил, оправдывайся.

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

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

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

Ну там аж два бага.

  1. Никто не запрещает обращаться к std::nullopt. Соответственно смысла от него чуть менее чем ничего.
  2. std::optional не даёт хранить ссылки. std::optional<int&> - ошибка.
RazrFalcon ★★★★★ ()
Ответ на: комментарий от fsb4000

Ну и зачем весь этот пердолинг? Речь-то идёт про идиоматичный код. И в данном случае разницы в скорости компиляции скорее всего не будет.

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

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

Более того, если взять контекст, а именно то предложение, которое ты выделил:

Это не вопрос каких-то соглашений для нормальной работы сложных систем, поддерживаемых десятилетиями коллективами из сотни программистов, нет, это сраный парсинг типа переменной!

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

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

std::optional не даёт хранить ссылки.

Ну тут я бы не считал это багом. А то вернут тебе из функции optional со ссылкой на переменную которая была выделенна на стеке и привет. Это ж не rust.

Хотя конечно остётся ещё возможность вернуть optional с указателем на эту переменную.

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

Хотя конечно остётся ещё возможность вернуть optional с указателем на эту переменную.

тут скорее std::reference_wrapper

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

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

«Стройная система костылей и подпорок»(цы)

Правда они начали всё-таки удалять всякую deprecated хрень в c++20.

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

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

ну у раста таких проблем нет и не будет - там в принципе не задумываются, что произойдет с существующим кодом лет через 10-15.

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

там в принципе не задумываются, что произойдет с существующим кодом лет через 10-15.

Задумываются. В частности в Rust есть такие гарантии от разработчиков:

Warning-free code on edition N must compile on edition N+1 and have the same behavior.

Редакции будут выходить раз в три года, как в плюсах. Пока есть Rust 2015 и Rust 2018, планируется Rust 2021

С совместимостью в Rust более менее хорошо, ломают только Nightly. Stable достаточно стабильный. Не десятки лет, но множество языков и библиотек не имеют даже таких гарантий…

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

Выходит что Warning-free code будет работать так же само 6 лет. Не представляю зачем нужно больше, но это все равно не 10-15.

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

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

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

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

Почему в среде линуксоидов его не выкидывают на мороз, как сишарп какой-нибудь?

Потому что люди не шизики, в отличии от.

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

если ты ламер, которому нечего написать по теме, то советую просто ничего не писать

Lrrr ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей