No warning for unrecognised top level keys on analysis_options

[FMorschel]

1. Create a new Flutter project with the latest stable
2. On analysis_options.yaml add:

lints:
  rules:
    prefer_relative_imports: true
    always_use_package_imports: true

This is not triggering incompatible_lint which I could see on latest main. Not sure if I'm doing something wrong here but I don't think so.

The rule 'always_use_package_imports' is incompatible with the rule 'prefer_relative_imports'.
Try removing one of the incompatible rules.dart(incompatible_lint)

CC @DanTup @pq

[FMorschel]

I just ran flutter create . (I had created with -e previously) and it works fine now. Will do some more testing.

[pq]

Thank you!

[FMorschel]

I've not yet been able to identify what is going on, but with this repro https://github.com/FMorschel/analysis I can't see any lints. I only see an unused_import diagnostic.

This time running flutter create . makes no difference. I'll see if any logs help me understand this better.

Edit:

New commit, I could trigger avoid_print and unused_local_variable which are all diagnostics but no lint. I also added prefer_int_literals but the code in main.dart triggers nothing and it has this line:

double test = 0.0, test2 = 0;

[FMorschel]

Also, I had tested the main branch on another project and figured it worked. When I swicthed for it on this project I could still not see any lints. Updated the title.

[FMorschel]

Here are the logs if anyone wants to take a look and see if they can find anything. I've disabled Dart-Code extension (and Flutter which depends on it), cleared the logs, enabled the extension, waited fo diagnostics to show up and a bit more, disabled the extensions again. This is the point where these were uploaded:

• extension.txt
• flutter_daemon.txt
• analyzer.txt
• daemon.txt
• dev_tools.txt
• InstrumentationLog.txt

[DanTup]

The reason for this is that you have lints: as the top-level key but it should be linter:. Therefore the code finds no enabled lints and reports nothing.

I guess we don't report anything on invalid top-level keys.. This might be deliberate (I think some plugins use this for configuration too?), though it does make issues like this difficult to spot (without stepping through code, which is how I noticed this). @bwilkerson @srawlins can probably confirm. If it's not deliberate, we could consider this a request to report on it. If it is and we need to allow unknown keys, I'm not sure if there's anything we could do to help with this?

[FMorschel]

Wow, I didn't even think to look at that line again.

Yes, some plugins do use this for configuration (DCM is one, at least they did when I could use them for my projects, not sure if they still do).

Couldn't we ask plugins the top-level keys they use? Or yet a better question, do we know when no plugins are enabled? In that case we could trigger something.

[srawlins]

I didn't think it was deliberate. But if DCM uses a top-level key, I guess we can continue to not report them. Or we could report them and allow the DCM top-level key.

[DanTup]

Couldn't we ask plugins the top-level keys they use? Or yet a better question, do we know when no plugins are enabled? In that case we could trigger something.

I think DCM is no longer an analyzer plugin, but runs its own LSP server, so this probably wouldn't work?

Or we could report them and allow the DCM top-level key.

This might not scale well if there are others (and if people have internal plugins, they might not want to have their names committed here). I did wonder if reporting anything that starts with "lint" that isn't "linter" would work, but I guess there's nothing to stop a third-party linter from using lints: 🙂

[FMorschel]

do we know when no plugins are enabled? In that case we could trigger something.

I think DCM is no longer an analyzer plugin, but runs its own LSP server, so this probably wouldn't work?

But it could at least be a partial solution? In the sense that if the user knows this is needed for something else, we could consider an # ignore or something here so this wouldn't go unnoticed at least? Not an ideal solution, I know, but it would solve the problem above.

[incendial]

Or we could report them and allow the DCM top-level key.

If you decide to start reporting unknown top level keys, we would really appreciate a reserved key, but I agree with @DanTup that this does not scale well.