Lint errors make it difficult to see code

[sunjay]

This is a screenshot of a function I'm in the middle of writing.

Here's the actual code in question:

    fn match_advanced_token(&mut self, start: char) -> TokenResult {
        if start.is_whitespace() {
            let spaces = String::new();

            let mut next_char = Some(start);
            while next_char.is_some() {
                let c = next_char.unwrap();
                if !c.is_whitespace() {
                    break;
                }

                spaces.push(c);
                next_char = self.scanner.get_char();
            }

            Ok(Token::Whitespace(spaces))
        }
    }

I'm not done writing the function yet, so there are a number of problems with it. The error being shown is complaining that not every return path results in the expected return type. This is a valid complaint, but because the error takes over the entire function and the bubble is impossible to dismiss, it's really difficult to write code.

Would it be possible to make the bubble dismissable somehow? Like just hit esc or something and tell it to leave me alone. Also, instead of highlighting every line in the function, could you just highlight one part and tell me the error?

For this specific error for example, you could just highlight the return type or the function name and complain that I'm not returning the same type in every control path. This is what a lot of linters like ESLint do.

[White-Oak]

1. The error takes not the whole function, but only the if block: this is a span that rustc gives back. It makes sense, but for the user convenience the linter should use not the span, but the 'highlighted text' fields from output. I'll get myself working on that, however, that'll take time. Thanks for the issue!

2. If you type anything in an error span, it will become unhighlighted, since the span changed and the linter cannot assume uncorrectness of this block -- this is probably what you want/need right now.

3. Of course, you can temporarily switch linter-rust off completely. Not sure if providing a shortcut will make sense, though.

[sunjay]

Thanks! I'll use your advice for now. Yeah I was a little confused as to why the red underlines suddenly disappeared. Sometimes the error would be shown in the list of errors at the bottom of the screen but clicking on it didn't do anything. This is probably because like you said, the linter can no longer verify the validity of the spans

[Arcanemagus]

As an FYI: Linter itself has a command to toggle the active editor, a simple way to disable linting temporarily on the file.

[White-Oak]

@Arcanemagus does Linter provide a way to highlight several spans per error? Errors in Rust are sometimes somewhat complex, one way to do this would be using trace messages of a linter message.

On a related note, I noticed that a Message v2 of Linter can no longer contain several trace messages (it now can contain only one reference point)'". Was it intended?

[Arcanemagus]

Messages can only have a single Range associated with them. Trace(s) would be the best way to solve that currently. Only one Trace was ever being used from what we saw, but I'm not sure why the ability to have multiple was removed. The API isn't completely finalized yet as it hasn't been released so @steelbrain might be persuaded to add that capability back in.

[steelbrain]

Hi @White-Oak, The reason behind removing several traces and adding only one description property is that it uses MarkDown and gives provider control over the appearance like never before, you can spread information in a format of your choice while also pulling docs from the web with http and make them all clickable (click to open url or click to open file).

[neu-rah]

Same issue, while implementing a trait I've compiled to check one function and now i have a box covering my code everytime i try to implement the other functions of the trait... I know its incomplete and it wont if linter lets me finish. putting that on the first line would be enough.
Disabling linter until this is corrected, this is too obtrusive.