#prog #rust хайлайты:
▪️Добавили линт на биндинги типа
▪️Стабилизировали ptr::addr_eq, которая сравнивает указатели по адресам без учёта метаданных.
▪️На
▪️Парсер теперь обрабатывает слайсинг с синтаксисом Python и предлагает использовать эквивалентный нативный синтаксис.
▪️К реализациям арифметических операций добавили #[track_caller].
▪️Серьёзность
▪️
▪️Стабилизировали {Rc, Arc}::unwrap_or_clone. Эти функции достают значение из счётчика ссылок при помощи клонирования, но избегают этого, если значение единственно.
▪️Реализация Vec::dedup_by теперь делает два прохода по вектору и начинает второй проход только в том случае, если элементы действительно нужно удалять. Это позволяет делать меньше работы для векторов уникальных значений, а также немного ускоряет все остальные случаи за счёт того, что теперь при перемещении элементов вместо
▪️Добавили линт на биндинги типа
(). Линт не срабатывает, если () есть явно с одной или иной стороны или тип явно записан, как (), также не работает на коде из макросов.▪️Стабилизировали ptr::addr_eq, которая сравнивает указатели по адресам без учёта метаданных.
▪️На
NonNull добавили методов с обычных указателей.▪️Парсер теперь обрабатывает слайсинг с синтаксисом Python и предлагает использовать эквивалентный нативный синтаксис.
▪️К реализациям арифметических операций добавили #[track_caller].
▪️Серьёзность
IMPLIED_BOUNDS_ENTAILMENT подняли с обычного линта до фатальной ошибки компиляции. Этот линт указывает на ситуации, когда реализация трейта из-за implied bounds (таких, как 'b: 'a в &'a &'b T) является более ограничительной, чем декларация трейта.▪️
LinkedList добавили retain{, _mut}▪️Стабилизировали {Rc, Arc}::unwrap_or_clone. Эти функции достают значение из счётчика ссылок при помощи клонирования, но избегают этого, если значение единственно.
▪️Реализация Vec::dedup_by теперь делает два прохода по вектору и начинает второй проход только в том случае, если элементы действительно нужно удалять. Это позволяет делать меньше работы для векторов уникальных значений, а также немного ускоряет все остальные случаи за счёт того, что теперь при перемещении элементов вместо
ptr::copy используется ptr::copy_nonoverlapping.GitHub
Add allow-by-default lint for unit bindings by jieyouxu · Pull Request #112380 · rust-lang/rust
Example
#![warn(unit_bindings)]
macro_rules! owo {
() => {
let whats_this = ();
}
}
fn main() {
// No warning if user explicitly wrote `()` on either side.
let expr = (...
#![warn(unit_bindings)]
macro_rules! owo {
() => {
let whats_this = ();
}
}
fn main() {
// No warning if user explicitly wrote `()` on either side.
let expr = (...
🎉5
Why are you all making restful services instead of, dunno, hard-working services or at least active ones?
👍13
#prog #rust #article
Semantic fuzzing of the Rust compiler and interpreter
Авторы сделали Rustlantis — фаззер, который генерирует программы на уровне MIR. Так как вывод программы предсказать заранее трудно, авторы применили подход differential testing: именно, они использовали несколько интерпретаторов и находили те программы, на которых они расходятся. Разумеется, подобный подход не имеет смысла для кода с UB, поэтому авторы специально написали генератор таким образом, чтобы избежать генерации UB.
В качестве верификаторов авторы использовали miri, компиляцию с помощью LLVM (с и без оптимизациями на уровне MIR) и Cranelift. Не смотря на крайне узкий охват пространства возможных программ, за 4,5 CPU-лет авторам удалось найти 13 новых багов.
Как видите, авторам не удалось найти баги, связанные с Cranelift, даже не смотря на то, что авторы ожидали противоположного. Авторы называют несколько возможных причин: cranelift намеренно не реализует много оптимизаций и он уже постоянно фаззится (аллокатор регистров — ещё и через symbolic execution).
*
Проектом заинтересовалась Rust foundation, так что есть шанс, что Rustlantis будет жить и развиваться дальше, а не помрёт, как очередная академическая штуковина.
*
Один из выявленных фаззером багов был спровоцирован, судя по фиксу, тем, что для одного из типов данных сравнение выполнялось неправильно: для него не была определена операция сравнения, но был определён неявный оператор каста в другой тип, для которого операция сравнения была, из-за чего сравнение начального типа учитывало лишь часть существенной информации.
Semantic fuzzing of the Rust compiler and interpreter
Авторы сделали Rustlantis — фаззер, который генерирует программы на уровне MIR. Так как вывод программы предсказать заранее трудно, авторы применили подход differential testing: именно, они использовали несколько интерпретаторов и находили те программы, на которых они расходятся. Разумеется, подобный подход не имеет смысла для кода с UB, поэтому авторы специально написали генератор таким образом, чтобы избежать генерации UB.
В качестве верификаторов авторы использовали miri, компиляцию с помощью LLVM (с и без оптимизациями на уровне MIR) и Cranelift. Не смотря на крайне узкий охват пространства возможных программ, за 4,5 CPU-лет авторам удалось найти 13 новых багов.
┌─────────┬──────────────┬─────┐
│ │Miscompilation│Crash│
├─────────┼──────────────┼─────┤
│rustc │ 3 │ 2 │
├─────────┼──────────────┼─────┤
│LLVM │ 6 │ 2 │
├─────────┼──────────────┼─────┤
│cranelift│ 0 │ 0 │
└─────────┴──────────────┴─────┘
*Как видите, авторам не удалось найти баги, связанные с Cranelift, даже не смотря на то, что авторы ожидали противоположного. Авторы называют несколько возможных причин: cranelift намеренно не реализует много оптимизаций и он уже постоянно фаззится (аллокатор регистров — ещё и через symbolic execution).
*
Проектом заинтересовалась Rust foundation, так что есть шанс, что Rustlantis будет жить и развиваться дальше, а не помрёт, как очередная академическая штуковина.
*
Один из выявленных фаззером багов был спровоцирован, судя по фиксу, тем, что для одного из типов данных сравнение выполнялось неправильно: для него не была определена операция сравнения, но был определён неявный оператор каста в другой тип, для которого операция сравнения была, из-за чего сравнение начального типа учитывало лишь часть существенной информации.
🔥14
Forwarded from Офигительные идеи🦄
А пооомните несколько лет назад ходило фото платья которые одни видели чёрно-синим, другие - жёлто-белым и в упор не понимали, как можно иначе?
Так вот. Я наткнулся на рисунок, который позволяет это ПОНЯТЬ, УВИДЕТЬ. ААААААААААА.
Так вот. Я наткнулся на рисунок, который позволяет это ПОНЯТЬ, УВИДЕТЬ. ААААААААААА.
🤯16👍3🤡2❤1
#prog #parsing #article
В Just write a parser (примечание к небольшому набору уроков по реализации парсера) автор выступает против глубокого изучения подходов к парсингу в курсах по обучению компиляторостроения и за то, чтобы забить на "академические" подходы и делать рекурсивный спуск руками. В качестве аргументов он приводит:
* Рекурсивный спуск очень хорошо даёт понять, как работает парсер, в отличие от генераторов парсеров.
* Это практичный навык: парсеры реальных компиляторов написаны вручную.
* Это не так уж и сложно.
В статье Why We Need to Know LR and Recursive Descent Parsing Techniques Laurence Tratt соглашается с первым тезисом (не перегружать курс по компиляторам подходами к парсингу), но оспаривает второй.
Именно, он указывает на LR-грамматики: такие грамматики точно являются однозначными, а то, является ли грамматика LR, можно проверить автоматически. Рекурсивный спуск же не даёт ясно понять, какова реализуемая парсером грамматика. В частности, реализуемая парсером грамматика может быть неоднозначной. Более того, то, что самописный рекурсивный спуск сам по себе вполне детерминирован, означает, что парсер таки разрешает неоднозначности грамматики, причём зачастую неочевидным способом.
Автор проводит параллель между валидатором грамматики и тайпчекером: прохождение проверки означает гарантию отсутствия определённых проблем (неоднозначностей грамматики и ошибок несовпадения типов соответственно). Более того, как он отмечает:
> If writing a grammar in LR style is hard for you as the language author, it will almost certainly be hard for users to understand!
Разумеется, автор признаёт, что не для всех языков возможно написать LR-грамматику в принципе, но он отмечает, что попытка написать такую грамматику может как минимум подсказать, где в реализации парсера могут крыться баги из-за неоднозначности.
Разумеется, это не всё, что есть в статье, так что советую прочитать целиком.
В Just write a parser (примечание к небольшому набору уроков по реализации парсера) автор выступает против глубокого изучения подходов к парсингу в курсах по обучению компиляторостроения и за то, чтобы забить на "академические" подходы и делать рекурсивный спуск руками. В качестве аргументов он приводит:
* Рекурсивный спуск очень хорошо даёт понять, как работает парсер, в отличие от генераторов парсеров.
* Это практичный навык: парсеры реальных компиляторов написаны вручную.
* Это не так уж и сложно.
В статье Why We Need to Know LR and Recursive Descent Parsing Techniques Laurence Tratt соглашается с первым тезисом (не перегружать курс по компиляторам подходами к парсингу), но оспаривает второй.
Именно, он указывает на LR-грамматики: такие грамматики точно являются однозначными, а то, является ли грамматика LR, можно проверить автоматически. Рекурсивный спуск же не даёт ясно понять, какова реализуемая парсером грамматика. В частности, реализуемая парсером грамматика может быть неоднозначной. Более того, то, что самописный рекурсивный спуск сам по себе вполне детерминирован, означает, что парсер таки разрешает неоднозначности грамматики, причём зачастую неочевидным способом.
Автор проводит параллель между валидатором грамматики и тайпчекером: прохождение проверки означает гарантию отсутствия определённых проблем (неоднозначностей грамматики и ошибок несовпадения типов соответственно). Более того, как он отмечает:
> If writing a grammar in LR style is hard for you as the language author, it will almost certainly be hard for users to understand!
Разумеется, автор признаёт, что не для всех языков возможно написать LR-грамматику в принципе, но он отмечает, что попытка написать такую грамматику может как минимум подсказать, где в реализации парсера могут крыться баги из-за неоднозначности.
Разумеется, это не всё, что есть в статье, так что советую прочитать целиком.
tiarkrompf.github.io
Tiark's Notebook
Tiark Rompf is an Associate Professor at Purdue University. Notes and blog posts on programming, research, CS, software systems.
👍11❤1🔥1
#prog #article
Debugging A Failing Hotkey
<...> So, yes, I’d just spent 30 minutes debugging a literally stuck key on my keyboard.
Debugging A Failing Hotkey
<...> So, yes, I’d just spent 30 minutes debugging a literally stuck key on my keyboard.
🔥16😁1
Forwarded from Лентач
Чинуши сменили желто-синий герб московского района Коптево
Глава Коптева Ольга Глаголева заявила «Подъёму», что прежний символ, который был утверждён почти 20 лет назад, не был зарегистрирован в Геральдическом совете.
Сам герб обновили в ноябре. По решению чинуш с левой части щита убрали фигуру солнца, добавив кресты. Почему понадобилось его менять именно сейчас, и с чем связано решение изменить цветовую гамму символов района не говорится.
Глава Коптева Ольга Глаголева заявила «Подъёму», что прежний символ, который был утверждён почти 20 лет назад, не был зарегистрирован в Геральдическом совете.
Сам герб обновили в ноябре. По решению чинуш с левой части щита убрали фигуру солнца, добавив кресты. Почему понадобилось его менять именно сейчас, и с чем связано решение изменить цветовую гамму символов района не говорится.
🤡29😁5👍2