should ignore statements implicitly apply to augmentations? about sdk

[bwilkerson]

An // ignore_for_class comment would presumably apply only to the class augmentation being written by the macro and not to the whole class, so (a) it's still a lexical range and (b) it isn't changing the semantics of an // ignore comment. The two things that I think are being suggested are to change the semantics of // ignore and to have an ignore comment on a base class implicitly apply to augmentations (or maybe even the other way around). I don't think we want to make either of those two changes.

(I do have a concern about the potential number of new ignore comment forms something like // ignore_for_class would require, but I don't have any problem with the general concept and I assume we can fine-tune the actual design.)

[jakemac53]

Or possibly // ignore_for_library, which would apply to all augmentations/parts of the library?

In general, I do not think most lints should apply to macro generated code though. It is not reasonable to expect macro generated code to conform to your projects lints or style.

The exception would be for security/correctness related lints.

[srawlins]

+1 to // ignore_for_library.

I think about this differently though, just for two cents: it is reasonable to expect a macro author to want the same static analysis in their macro-generated augmentations (avoid_types_as_parameter_names ("whoops!"), await_only_futures ("oh, I see"), collection_methods_unrelated_type ("good catch!"), etc). An exception then might be style-motivated rules.

It's effectively third-party code that just happens to belong to the same package.

I agree, but hope we can reliably determine whether the augmentations are being generated into the same package as where the macro definition lives, to support the above author experience in their test cases and examples. Another example of this motivation is errors and warnings: we do not report errors and warnings in third party code (e.g. in your pub dependencies), but it is reasonable to expect a package author to be informed when they are generating code that newly violates deprecated_member_use or deprecated_colon_for_default_value, etc.

[lrhn]

I agree, but hope we can reliably determine whether the augmentations are being generated into the same package as where the macro definition lives

The macro code belongs to the package of the library that it is generated into a part of.
All the fiddling with dart-macro+package: URIs was to give the generated code a unique location that was also able to be recognized as in the same package.

I don't expect to support a library having code that belongs to different packages.
(If for no other reason, then because the two packages might have different default language versions.)

[bwilkerson]

I agree.

We support ignoring a diagnostic of a specific kind on a specific line, and ignoring a kind of diagnostic for a whole file, but we don't support ignoring diagnostics within a specific declaration.

If we wanted to support the latter case then we'd need to decide how that works in the face of augmentations, but without that I think that augmentations should have no impact.

[srawlins]

We actually have considered adding something like // ignore_for_class specifically for macros. The idea is that all macro applications for a single library ultimately result in a single library augmentation. So if one macro author writes their macro to generate // ignore_for_file in the generated code, that might apply to all code in the augmentation, from all macro applications. How can we support a macro author who wants to suppress diagnostics in their code that they write into a library augmentation.

[lrhn]

What @jakemac53 says: Macro generated code is generated code, and shouldn't be linted the same way as user written code.
It's effectively third-party code that just happens to belong to the same package.