Packages: [Rust] Incorrect error highlighting with nested array template arguments

Created on 25 May 2017  路  3Comments  路  Source: sublimehq/Packages

I'm using Sublime Text 3, Dev Build 3131 on macOS Sierra. The second semicolon gets erroneously highlighted as error in the last two cases:
incorrect-highlighting

Most helpful comment

@FichteFoll

Am I right to assume that Rust allows array lengths in type declarations that are known at compile time, including compiler optimizations like resolving constants such as N above or simple arithmetics, as seen with 5+1? (Consequently, N+1 as well?)

Your assumption is correct. The Rust (fixed-sized) array type notation [T; N] means an array of N elements of type T, where N must be a compile-time known expression of type usize (which is basically an unsigned integer). Box is basically a type template (in C++ speak) which is parameterized by one type parameter, and therefore the notation Box<T>, where T is some actual type, means an actual type instantiation. Compile-time constant values can be created with the notation const MY_VALUE: T = N;, where T is a type and N is a compile-time known expression (the convention is to name constants using screaming snake case). For example, the following is legal albeit unlikely Rust code:

const FOO: usize = 5;

let _: Box<[[bool; (FOO + 1) / 2]; FOO * 3 % 12 - 1]>;

All 3 comments

I don't know Rust syntax well enough to be confident about how to fix it, but it looks like it is this pattern here that causes it: https://github.com/sublimehq/Packages/blob/b506d85ef0badfbdbe18f75f02cfa4588b18d574/Rust/Rust.sublime-syntax#L472-L473

Removing that pop pattern completely means that the + no longer gets scoped though, so I guess it needs to copy the + scoping from https://github.com/sublimehq/Packages/blob/b506d85ef0badfbdbe18f75f02cfa4588b18d574/Rust/Rust.sublime-syntax#L478-L479 in place of the \S lookahead pop pattern.

EDIT: after making said change, the existing syntax tests still pass, so that's a good sign. But I guess that, for completeness, the N should be scoped as for "usage of constant" i.e. variable.other.constant?

Am I right to assume that Rust allows array lengths in type declarations that are known at compile time, including compiler optimizations like resolving constants such as N above or simple arithmetics, as seen with 5+1? (Consequently, N+1 as well?)

In that case, it might make sense to introduce a special size context that matches the allowed expressions in array declarations. Or alternatively just arbitrary expressions and let the compiler/linter complain.

@FichteFoll

Am I right to assume that Rust allows array lengths in type declarations that are known at compile time, including compiler optimizations like resolving constants such as N above or simple arithmetics, as seen with 5+1? (Consequently, N+1 as well?)

Your assumption is correct. The Rust (fixed-sized) array type notation [T; N] means an array of N elements of type T, where N must be a compile-time known expression of type usize (which is basically an unsigned integer). Box is basically a type template (in C++ speak) which is parameterized by one type parameter, and therefore the notation Box<T>, where T is some actual type, means an actual type instantiation. Compile-time constant values can be created with the notation const MY_VALUE: T = N;, where T is a type and N is a compile-time known expression (the convention is to name constants using screaming snake case). For example, the following is legal albeit unlikely Rust code:

const FOO: usize = 5;

let _: Box<[[bool; (FOO + 1) / 2]; FOO * 3 % 12 - 1]>;
Was this page helpful?
0 / 5 - 0 ratings