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)

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

DSP есть без байтовой адресации. Впрочем никто не мешает сделать как в С для pdp-10 с семибитными байтами, упакованными по пять штук в 36-жирное слово.

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

DSP есть без байтовой адресации.

Эм, какой же?

Впрочем никто не мешает сделать как в С для pdp-10 с семибитными байтами, упакованными по пять штук в 36-жирное слово.

Ну т.е. Вы признаете, что нет современных процессоров с байтом размерностью <> 8 бит и машинным словом не 32\64.

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

ещё вспомни про 31битный s390

s390 - 32битовый; 31 бит - это разрядность адреса.

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

DSP есть без байтовой адресации.

Эм, какой же?

NM6403 и некоторые линии TMS320

т.е. Вы признаете, что нет современных процессоров с байтом размерностью <> 8 бит и машинным словом не 32\64.

В MSP430 16-бит слово. И на нем даже есть кое-какой Rust.

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

Есть ещё другие компиляторы, например mrustc

«In-progress», «mrustc works by comping assumed-valid rust code (i.e. without borrow checking) into a high-level assembly (currently using C)» - нет.

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

И что с этим не так?

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

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

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

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

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

Он пишется для целевых платформ, где нет LLVM, так что нет, не вызывает

Это откуда? В описании «This project is an attempt at creating a simple rust compiler in C++, with the ultimate goal of being a separate re-implementation». И в планах есть и проверки, и LLVM и пр. Так что это просто проект на раннем этапе, и что из него выйдет, и не забросят ли его, будет видно только потом.

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

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

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

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

Он пишется для целевых платформ, где нет LLVM, так что нет, не вызывает

Это откуда?

Это с reddit.

with the ultimate goal of being a separate re-implementation

ultimate

В неопределенном будущем.

Так что это просто проект на раннем этапе, и что из него выйдет, и не забросят ли его

Да. Но сейчас он есть.

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

одно время у них были типы int/uint полностью аналогичные C-шным, как я понимаю

Вроде аналогичный uintptr_t, всё таки инты сейчас везде (или почти везде) 32 бита.

И ещё вопрос - как у Rust с поддержкой типа long double который 80 бит?

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

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

Возможно, хотя imho, uintptr_t это не совсем int. Это что-то, что может вмещать как int, так и адрес. Для реального режима 86 процессора, он-бы был (если-бы тогда о нём озаботились), например, 32 бита, несмотря на то, что int там - 16 бит, ну и сейчас, насколько я понимаю, для x86_64 в Unix-ах (LP64) int вполне себе 32 бита, а uintptr_t - 64.

А по-поводу библиотек - так и в C при помощи оных можно прицепить что угодно и как угодно, начиная с разбора xml-ей и прочих json-ов, заканчивая ООП.

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

NM6403

С wiki =>

Разработан в 90-х годах, изготовлен в 1998 году на фабрике Samsung.

Второй же

It was introduced on April 8, 1983 through the TMS32010 processor, which was then the fastest DSP on the market.

Я писал ранее =>

Ну т.е. Вы признаете, что нет современных процессоров с байтом размерностью <> 8 бит и машинным словом не 32\64.

Чувак, первому DSP уже 20 лет, какой разумный человек будет его использовать в проекте? Я уже не говорю, что второму 35 лет. Если для Вас это офигительно современный процессор, то мне Вас жаль

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

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

Эти процессоры до сих пор выпускаются, так что да, они современные.

Чувак, первому DSP уже 20 лет, какой разумный человек будет его использовать в проекте?

Ну вот, началось - выши доказательства не доказательства.

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

Ну вот, началось - выши доказательства не доказательства.

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

А по теме объективно, современных архитектур нет где бы int был не в 4/8 байт. А современный байт исключительно 8 бит.

Вывод из этого, что поддержка иной битности в байте и плавающая от платформы размерность чисел - это атавизм. И Си не имеет значимого преимущества перед Rust'ом. Ну конечно, если Вам вдруг не захотелось по программировать для Cray-1 или ранних PDP, но на сколько я знаю, за это сейчас денег не платят.

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

Именно поэтому drop превратился в финализатор, как и в других языках программирования с автоматическим управлением памяти

Астановись

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

Ну закидай меня ещё в добавок тупыми вопросами.

У меня нет к тебе вопросов.

если Вам вдруг не захотелось по программировать для Cray-1 или ранних PDP, но на сколько я знаю, за это сейчас денег не платят.

Кстати, хорошее определение «современного процессора» - тот, за программирование на котором платят деньги.

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

1) В сравнении с плюсами, rust не предоставляет ничего особенного, т.к. концепция rust - есть всего-навсего плюсовое RAII, сделанное обязательным

2) Несмотря на то, что RAII в rust вроде бы обязательно, rust не может контролировать его обязательность по всему проекту, т.к. есть unsafe => как и в случае с плюсами без кодгайдов не обойтись

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

4) Его придётся учить. Зачем?

5) Плюсы ругают за закорючки и невменяемые сообщения об ошибках, в раст это не поправлено.

6) убогое ООП по сравнению с плюсами

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

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

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

Как хорошо, что borrow checker и lifetimes уже давно внедрили во все указанные языки, а твой пост не эталонное 4.2.

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

1) В сравнении с плюсами, rust не предоставляет ничего особенного, т.к. концепция rust - есть всего-навсего плюсовое RAII, сделанное обязательным

Это, конечно же, вранье. Из того, чего в Си++ нет совсем, в Rust есть pattern matching, лайфтаймы и модули.

2) Несмотря на то, что RAII в rust вроде бы обязательно, rust не может контролировать его обязательность по всему проекту

unsafe отключается прагмой или (если нужно по всему проекту) отыскиваются стандартным линтером.

5) Плюсы ругают за закорючки и невменяемые сообщения об ошибках, в раст это не поправлено.

Сообщения об ошибках в Rust вполне вменяемы.

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

Это proof of concept, не более. Ждем C++26... или не ждем.

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

Вот Pattern matching, как ни странно, есть: https://github.com/solodon4/Mach7

Этот pattern matching умеет матчить что-то, кроме variant? А проверка на exhaustiveness в нем есть? А можно уточнить case условием? Если нет, то это Си++-акробатика, а не pattern matching. Это лучше, чем ничего, но это эрзац.

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

pattern matching плюсах делается на макросах, lifetimes - частный случай RAII, a модулей действительно нет, но они есть в D и Go и я не стал упоминать про эту мелочь

отыскиваются стандартным линтером

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

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

lifetimes - частный случай RAII

фейспалм.жпг

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

по поводу ошибок: наверное поэтому самый популярный запрот о раст «Why does Rust borrow checker reject this code?»

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

Оба - попытки сделать RAII обязательным

Обязательный RAII можно сделать и в плюсах запретом на new, delete и указатели. Но от этого lifetimes и borrow checker в плюсах не появится, а твой коммент не перестанет быть 4.2

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

Обязательный RAII можно сделать и в плюсах

можно

запретом на new, delete и указатели

Ясно. Рекомендую вам всё же ознакомиться с концепцией RAII.

от этого lifetimes и borrow checker в плюсах не появится

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

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

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

На stackoverflow описаны причины нескольких классов таких ошибок и как от них избавиться. И это, похоже, уже большинство классов ошибок - новые появляются редко.

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

можно

Ну же, продемонстрируй

Рекомендую вам всё же ознакомиться с концепцией RAII.

А тебе всё же стоит ознакомиться с lifetimes и borrow checker в Rust

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

Ну так это и будет копирование. Причём такой swap надо будет реализовывать самому: в этом разница мувов раста и плюсов. В плюсах на уровне синтаксиса нет понятия перемещения, есть просто особый вид ссылок и перегрузка. То, что это перемещение, для класса нужно реализовать самому. В Расте перемещения реализованы на уровне языка, любая структура умеет копироваться или перемещаться сама. В результате, ситуацию «объект уже перемещён, вызывать деструктор не надо» в C++ решает программист в рантайме, меняя что-то в источнике перемещения (например присваивая умному указателю null) и обрабатывает эту ситуацию в деструкторе. В Расте за этим следит компилятор, либо статически выясняя, что объект переместился и вызывать деструктор не надо, либо сохраняя эту информацию где-то сбоку. Поэтому стандартная move-семантика недоступна для заимствованых даже эксклюзивно объектов, чтоб реализовать ваш метод необходимо колхозить мувы как в C++ самому.

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

Ну же, продемонстрируй

Ok. Пиши тему в разделе job. О цене, сроках, деталях выполнения заказа договоримся там.

А тебе всё же стоит ознакомиться с lifetimes и borrow checker в Rust

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

Т.е., полный перечень проблем от которых защищают растоспецифичные механизмы в однопотоке: утечка ресурсов, выход за пределы Околлекции, чтение из неинициализированного указателя, чтение по нулевому адресу, освобождение памяти неподходящими средствами (грубо говоря, вызов free() для памяти выделенной через new). И даже от переполнения стека, он, например, не защищает.

Поправьте меня, если я не прав.

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

В C++ есть std::move

Почувствуй разницу.

#include <iostream>
#include <utility>
#include <vector>

int main() {
    std::string s = "str";
    std::string m(std::move(s));
    std::cout << "s = \"" << s << "\"" << std::endl;
    return 0;
}
$ g++ -Wall move.cpp -o move-cpp
$ ./move-cpp 
s = ""
fn main() {
    let s = String::from("str");
    let _m = s;
    println!("s = \"{}\"", s);
}
$ rustc move.rs 
error[E0382]: use of moved value: `s`
 --> move.rs:4:28
  |
3 |     let _m = s;
  |         -- value moved here
4 |     println!("s = \"{}\"", s);
  |                            ^ value used here after move
  |
  = note: move occurs because `s` has type `std::string::String`, which does not implement the `Copy` trait

error: aborting due to previous error
anonymous
()
Ответ на: комментарий от anonymous

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

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

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

Как же std::move избавляет от необходимости писать конструктор и оператор перемещения? Ваш. Кэп.

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

Не избавляет, но упрощает перемещение.

Упрощает? Кастом в xvalue expr? Перемещение, перевод объекта в неопределённое состояние, реализуется программистом. Компилятор не проводит никаких проверок во время компиляции, то есть «семантика» проверяется программистом. Ооооочень упрощает. Ага.

Ваш Кэп.

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

Почувствуй разницу.
g++

test.cpp:8:30: error: 's' used after it was moved [hicpp-invalid-access-moved,-warnings-as-errors]
    std::cout << "s = \"" << s << "\"" << std::endl;
                             ^
test.cpp:7:17: note: move occurred here
    std::string m(std::move(s));
                ^
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.