Stream: t-compiler/wg-rls-2.0

Topic: Customizable Diagnostic Levels


Jonas Schievink (Jul 24 2020 at 12:56, on Zulip):

I'd like to add a way to opt out of individual diagnostics (since the "mismatched arg count" has a couple of false positives), and was thinking that we might want to have a more granular way to configure severity of diagnostics.

I see that the default CSS plugin allows configuring various lint levels, maybe we want to have the same? Perhaps not on a per-diagnostic level, but I think it would be nice to have individual opt-outs for things like missing match arms (which also occasionally gives false positives) and other diagnostics. Thoughts?

Jonas Schievink (Jul 24 2020 at 13:06, on Zulip):

If we don't want this, I'd just add a "Enable Experimental Diagnostics" toggle instead that turns off diagnostics with many false positives.

Jonas Schievink (Jul 24 2020 at 13:08, on Zulip):

Maybe "experimental" should include MissingOkInTailExpr, since that's just a limited mismatched types diagnostics and I've seen an issue about false positives for that one too

Florian Diebold (Jul 24 2020 at 13:18, on Zulip):

I think we might want both -- I think a "enable experimental diagnostics" toggle would be a good idea so we can introduce more of them and not have people need to toggle each of them off separately, but also configuring specific diagnostics would be good (though long term that should happen through attributes)

Jonas Schievink (Jul 24 2020 at 13:18, on Zulip):

Attributes as in #[attributes]?

Florian Diebold (Jul 24 2020 at 13:18, on Zulip):

maybe we could even have levels of experimental diagnostics, so we could have a super spammy level where we give a diagnostic for every type mismatch (though I might be the only person who enables that :sweat_smile: )

Florian Diebold (Jul 24 2020 at 13:18, on Zulip):

yeah

Jonas Schievink (Jul 24 2020 at 13:19, on Zulip):

That sounds like a good fit for hints and warnings, but maybe not for error diagnostics

Florian Diebold (Jul 24 2020 at 13:19, on Zulip):

hm that's true

Florian Diebold (Jul 24 2020 at 13:19, on Zulip):

ok, long-term error diagnostics should be perfect anyway ;)

Jonas Schievink (Jul 24 2020 at 13:20, on Zulip):

heh, yeah

Florian Diebold (Jul 24 2020 at 13:20, on Zulip):

so, a general toggle seems more important and useful to me right now

Florian Diebold (Jul 24 2020 at 13:30, on Zulip):

OTOH maybe we want people to have to disable each diagnostic separately...

Jonas Schievink (Jul 24 2020 at 13:31, on Zulip):

I kinda do :)

Florian Diebold (Jul 24 2020 at 13:33, on Zulip):

well... I kind of want to have a place for super-experimental diagnostics, and then have them graduate to a default-on state where people can still disable them. I think it's useful if you can add a diagnostic in a not-yet-ready-for-general-consumption state

Florian Diebold (Jul 24 2020 at 13:34, on Zulip):

I guess that would be possible with specific toggles as well though

Florian Diebold (Jul 24 2020 at 13:34, on Zulip):

soo yeah, maybe individual toggles are the better approach after all :sweat_smile:

Jonas Schievink (Jul 24 2020 at 13:35, on Zulip):

If we change the default setting, will that update within VS Code or will the old default be kept?

Florian Diebold (Jul 24 2020 at 13:36, on Zulip):

I think we can implement defaults on server side that apply if the setting hasn't been explicitly set by the user?

Jonas Schievink (Jul 24 2020 at 13:37, on Zulip):

Oh, yeah, we already have that

Jonas Schievink (Jul 24 2020 at 13:37, on Zulip):

But the plugin-side also has defaults, maybe they're optional though

Florian Diebold (Jul 24 2020 at 13:40, on Zulip):

yeah I don't know how those work

matklad (Jul 24 2020 at 13:43, on Zulip):

In the stupidest way possible

matklad (Jul 24 2020 at 13:43, on Zulip):

Even if the user has nothing in their settings, VS Code will gladly stomp over every server default

Florian Diebold (Jul 24 2020 at 13:43, on Zulip):

hrm

matklad (Jul 24 2020 at 13:43, on Zulip):

But I don't think unsynced defaults are a big problem

Florian Diebold (Jul 24 2020 at 13:44, on Zulip):

well, actually the Emacs impl will kind of do the same

matklad (Jul 24 2020 at 13:44, on Zulip):

Like, they'll converge eventually

Florian Diebold (Jul 24 2020 at 13:44, on Zulip):

maybe we want to model this as two settings "disabled diagnostics" and "enabled experimental diagnostics" that are just lists of strings anyway?

matklad (Jul 24 2020 at 13:46, on Zulip):

Yeah, this seems like the best solution

matklad (Jul 24 2020 at 13:46, on Zulip):

Well, impl-wise, for every diagnostic we should have either "on" or "off", without distinguishing experimental from non-experimental ones

matklad (Jul 24 2020 at 13:47, on Zulip):

but two lists in the UI seem good!

Florian Diebold (Jul 24 2020 at 13:47, on Zulip):

yeah

Jonas Schievink (Jul 24 2020 at 14:32, on Zulip):

Hmm, can we accept an arbitrary string-keyed map as a setting? Then each diagnostic can be mapped to a severity instead of just turned on or off.

Jonas Schievink (Jul 24 2020 at 14:33, on Zulip):

Like, having a general type mismatch diagnostic that emits errors would be too noisy, but not necessarily if it's only at hint level

Jonas Schievink (Jul 24 2020 at 14:33, on Zulip):

And when users turn it off completely, they miss out on quick fixes

Florian Diebold (Jul 24 2020 at 14:38, on Zulip):

initialization options are any, so... I guess?

Florian Diebold (Jul 24 2020 at 14:38, on Zulip):

that would also make it just one map instead of two lists, which is nice

Florian Diebold (Jul 24 2020 at 14:39, on Zulip):

well, I guess it's possible that VSCode doesn't allow arbitrary JSON as settings, I can't speak to that

matklad (Jul 24 2020 at 14:39, on Zulip):

Yup, map would be fien

Jonas Schievink (Jul 24 2020 at 14:42, on Zulip):

Can you provide custom settings UI or would this just be a JSON entry box for users? :D

matklad (Jul 24 2020 at 14:44, on Zulip):

I think it'll be JSON

matklad (Jul 24 2020 at 14:44, on Zulip):

Seems fine by me

matklad (Jul 24 2020 at 14:44, on Zulip):

we are not going to have many false positives, are we? :D

Jonas Schievink (Jul 24 2020 at 14:46, on Zulip):

I meant this to also be the way to configure warnings and hints, and for those a nicer UI would be good

Jonas Schievink (Jul 24 2020 at 14:55, on Zulip):

Clearly package.json needs to be produced by xtask

Jonas Schievink (Jul 24 2020 at 15:29, on Zulip):

I'll just go with the experimental diagnostics checkbox for now. Is there a way to invalidate existing diagnostics when the box is (un)checked?

matklad (Jul 24 2020 at 15:32, on Zulip):

@Jonas Schievink sudo reboot? I'd punt on this for the time being

Jonas Schievink (Jul 24 2020 at 15:33, on Zulip):

I could maybe add it to requiresReloadOpts

Last update: Sep 27 2020 at 14:45UTC