@nolint syntax attribute

[nnullcolumn]

rendered

[Kampfkarren]

Are attributes supported outside statements yet? You would need to support everything, including expressions, in order for this to be better than a comment.

It also feels weird to both repeatedly mention the use case for external tooling and linters and also say:

However, it seems like linting will eventually move to being the sole responsibility of lute

In which case, custom tooling has to not support this, since they don't want their names being linted.

I think that problem clears up with namespacing (e.g. @nolint("lute.ABC"), making it the responsibility of the namespace to check for valid lints, while Luau itself lints any other name in the global namespace that it doesn't recognize.

[nnullcolumn]

Are attributes supported outside statements yet? You would need to support everything, including expressions, in order for this to be better than a comment.

this RFC proposes allowing that for an @nolint attribute. I don't think we should rely on comments.

It also feels weird to both repeatedly mention the use case for external tooling and linters and also say:

However, it seems like linting will eventually move to being the sole responsibility of lute

In which case, custom tooling has to not support this, since they don't want their names being linted.

sorry, i don't think i communicated too well. might need to update the body a bit. i was thinking .config.luau or similar would help configure to

A) ignore it entirely

B) specify all of the lints we care about

that was what i meant when i wrote "emit a configurable warning in and of itself"

I think that problem clears up with namespacing (e.g. @nolint("lute.ABC"), making it the responsibility of the namespace to check for valid lints, while Luau itself lints any other name in the global namespace that it doesn't recognize.

this seems nicer than what i originally had in mind / mentioned above. it'd probably require changing the .config.luau structure up a bit, but seems like a big improvement

p.s., @nolint("foo") is currently disallowed syntax. you're forced to do @[nolint("foo")] for parameters.

[andyfriesen]

If we built this system using comments as an extension to --!nolint, we could implement it entirely within the linter itself. No changes to the language would be necessary.

How about this:

We change the meaning of --!nolint so that it can occur at any position in the file. We change its meaning to indicate that, from its position on, the named lints should be disabled.

We also add a new hot comment --!poplint (name TBD) which has the effect of undoing the prior --!nolint:

blah blah

--!nolint A
lint A is disabled here

--!nolint B, C
A, B, and C are disabled here
--!poplint

Only A is disabled here
--!poplint

-- back to default settings

[nnullcolumn]

If we built this system using comments as an extension to --!nolint, we could implement it entirely within the linter itself. No changes to the language would be necessary.

How about this:

We change the meaning of --!nolint so that it can occur at any position in the file. We change its meaning to indicate that, from its position on, the named lints should be disabled.

We also add a new hot comment --!poplint (name TBD) which has the effect of undoing the prior --!nolint:

blah blah

--!nolint A
lint A is disabled here

--!nolint B, C
A, B, and C are disabled here
--!poplint

Only A is disabled here
--!poplint

-- back to default settings

--! comments historically have only been used at the top of a module AFAIK. That aside, this feels very unsatisfying:

• refactoring code can involve cutting and pasting things here to there, which might miss comments

• you can't easily do things like @nolint fun(), which is kinda unfun. i don't want to add potentially multiple lines of comments that effectively serve to be visual noise

• forgetting to pop the lint would really hurt because it'd be more or less silent

  • there are some mitigations for this; we maybe able to warn people if they forget to pop a nolint but that in and of itself is kinda an example of something that could get awkward when multiple implementors are involved

• the range isn't entirely obvious and if you're skimming you might end up with confusing linter behavior; we shouldn't let these cross multiple lexical scopes IMO.

• we run into trouble if we ever want to extend the possible params for nolint

among many other things. I don't think comments do this job well on their own, or I would've opened with one of the comment-based alternatives I already listed. I'm very much in favor of not relying on mid-file hot comments for developer experience, especially as someone who has been unsatisfied with comment-based silencing in external linters and other languages.

Is extending the language a dealbreaker?

[andyfriesen]

Is extending the language a dealbreaker?

mmm. I don't think so.

#[allow(X)] really is quite nice in Rust.

[andyfriesen]

Rust uses allow which seems a bit strange if you're reading it in a spec, but when you're reading actual code, #[allow(unused)] reads very clearly.

[nnullcolumn]

i think i'll probably remove the alternative which is highlighted because it makes almost no sense. i'll also add an alternative for allow, but i think @nolint makes more sense in the context of luau because you wouldn't be forced to specify specific lint rules. @[allow("LocalUnused")] or similar would be nice, but @allow call() on its own reads in a way that irks me a bit.