
Кое-что я при разработке этого макроса упустил: проверка на недостижимость кода недостаточно точна. Если строка не начинается с префикса, скажем,
"java"
, то пытаться отщипнуть префикс "javascript"
уже не имеет смысла, потому что он заведомо отсутствует. Однако мой макрос проверяет строки на (не)равенство и не учитывает их возможных структурных отношений. Сейчас мы это исправим, и пойдём по уж проторенной дорожке: вынесем нужную проверку в const fn
и будем генерировать код, который не тайпчекается в случае, если проверка завершилась неудачей.Начнём с выяснения того, является ли одна строка префиксом другой. Ничего сложного в этом нет (кроме того, чтобы перепутать одну строку с другой, ага), просто несколько неудобно из-за ограничений const fn:
const fn is_prefix(s: &str, maybe_prefix: &str) -> bool {Теперь немного подумаем о том, как детектировать недостижимые паттерны. Для этого нам нужно перебрать все пары различных строк из
if maybe_prefix.len() > s.len() {
return false;
}
let s = s.as_bytes();
let mp = maybe_prefix.as_bytes();
let mut i = 0;
while i < mp.len() {
if mp[i] != s[i] {
return false;
}
i += 1;
}
true
}
match
и проверить, что для каждой такой пары строка из более поздней ветки не является префиксом строки из более ранней ветки. Так? Так, да не совсем: у ветки может быть охранное выражение, и в этом случае выполнение ветки может не произойти по совершенно произвольным причинам. Поэтому в генерируемом коде мы будем хранить не только строки, но и признак того, что охранное выражение есть, и при в соответствующей функции будем эти строки пропускать. Сказано — сделано:const fn has_unreachable_patterns(ss: &[(&str, bool)]) -> bool {Осталось только сгенерировать код для проверки, заменив в макросах функцию
if ss.is_empty() {
return false;
}
let mut i = 0;
let mut j;
while i < ss.len() - 1 {
// строки, для которых есть охранное выражение, пропускаем
if ss[i].1 {
i += 1;
continue
}
j = i + 1;
while j < ss.len() {
// А вот вторую строку в паре нужно проверять всегда,
// вне зависимости от того, есть у него охранное выражение или нет:
// если охранного выражения нет у первой строки, то исполнение
// до ветки со второй строкой точно не дойдёт.
if is_prefix(ss[j].0, ss[i].0) {
return true;
}
j += 1;
}
i += 1;
}
false
}
non_repeating
(это изменение, кстати, одинаковое для всех двух (трёх) макросов) — и это, кажется, наиболее зубодробительная часть:const _HAS_NO_UNREACHABLE_PATTERNS: [(); 0] = [Это довольно много, так что разберём по частям:
();
has_unreachable_patterns(
&[
$((
$prefix,
false $(|| {stringify!($condition); true})?
),)*
]
) as _
];
const _HAS_NO_UNREACHABLE_PATTERNS: [(); 0] = [Это объявление константы. Если
();
has_unreachable_patterns(...) as _
];
has_unreachable_patterns(...)
вычисляется в true
, то оно при касте в usize
становится 1
, вызывая ошибку несоответствия типов.&[Здесь мы формируем ссылку на литерал массива, элементами которого являются пары, первыми элементами которых являются строки-префиксы.
$((
$prefix,
...
),)*
]
false $(|| {stringify!($condition); true})?Здесь мы формируем значение
true
, если охранное выражение имеется. Сделать повтор синтаксического фрагмента без соответствующей синтаксической метапеременной нельзя, но и само выражение нам не требуется, поэтому воспользуемся стандартным трюком: переведём выражение в безвредную строку и отбросим её. На итоговое выражение это не повлияет, а наличие нужной метапеременной обеспечено. И да, это не замыкание, как может показаться, а выражение с оператором "или".use_prefixes
:fn use_prefixes(s: &str) -> String {Эта функция закономерно вызывает жалобы у компилятора на несоответствие типов. Отлов ошибок работает! Теперь немного поменяем определение:
prefixes!(match s {
"foo".. => s.to_string(),
"bar".. => [s, s].concat(),
"foobar".. => [s, "3"].concat(),
_ => String::new(),
})
}
fn use_prefixes(s: &str) -> String {...И теперь у компилятора нет вопросов.
prefixes!(match s {
"foo".. if true => s.to_string(),
"bar".. => [s, s].concat(),
"foobar".. => [s, "3"].concat(),
_ => String::new(),
})
}
Есть недостатки у нашего решения? Определённо — помимо тех, о которых я уже писал. Во-первых, теперь это жёсткая ошибка вместо предупреждения компилятора — но да, это спорный недостаток. А во-вторых — и вот это уже недостаток куда как более существенный — ошибка компиляции не говорит о том, какие паттерны перекрываются. И я, к сожалению, не придумал, как их показывать, не выходя за пределы того, что умеет stable Rust.