Oh, and another open question (that very much fits into this thread): I sometimes come across patterns where we want lints that subsume each other. E.g. (not yet written) unicode should subsume zero_width_space.
So, I want the following behavior:
#[warn(unicode, zero_width_space)] is the same as #[warn(unicode)].
#[deny(unicode)] #[warn(zero_width_space)] should only generate the unicode error, not warn of the zero width space in addition.
#[warn(unicode) #[deny(zero_width_space)] should warn on all unicode characters and also deny zero-width space characters. In this case, as the unicode spans fully contain the zero-width-space spans, only warn if both spans arenāt equal.
However, this is not at all trivial to write.
Another example: Letās say I want a string_add and a string_add_assign lint (where the former lints all + on Strings, while the latter only lints x = x + .. where x is a String). Obviously the former subsumes the latter (because it matches all its occurrences), but a) the resulting span is smaller and b) there is no simple way to find out if the outer expression is a self-assignment when visiting the inner BinaryExpr (x + ..).
This is all quite complex. Perhaps we could add some supporting code in the compiler?
It is an open question, and one Iām willing to pass the buck on for a more thorough discussion to happen first. For instance, Iād rather get the error about unicode and a warning that thereās a zero-width space in the second case. If I cannot see zero-width strings, I want to be told about them clearly. But yeah, itās also a difficult thing to write. Perhaps open a new discussion topic on that specifically?
I honestly have no clue what --verbose is supposed to do. Who is the end user of the flag and what user stories does is solve? Without that, I cannot write any guidelines for it.
About --verbose: (Perhaps) augment Error/Help messages with more direct information. E.g. clippy sometimes suggests code snippets that are built from a mix of predefined code and the given source code. However, if that code is large, it can lead to a lot of output. A good compromise is to show only a short generic snippet in those cases unless --verbose is added.
Also I think that spans should be shortened (with ellipsis) if they are longer than 3-4 lines unless --verbose is given. This makes sure that the normal output is fairly compact.
Btw. with JSON output, the verbose version should be the default, IMHO.
Iām trying to document guidelines currently in place - not design new ones. In this case, I cannot find any examples of using --verbose in rustc to show more information while compiling.
Ok, agreed, let's first outline what we have. This is a good starting point for an RFC.
Also, from your RFC text:
A note is for ... (anything else?)
A note is for identifying additional circumstances and / or parts of the code that lead to the warning/error. E.g. lint warnings/errors will automatically note the section of the code that activated the lint, if any. The borrow checker will note any previous conflicting borrow.