Code change:
I tried this code: I expected to see this happen: no warnings Instead, this happened: : cc
It looks like there is an upstream issue about this , but it seems like this shouldn't be an issue for dependents as long as is on edition < 2024.
It is expected for the lint to lint on macro-generated code. It is also expected for the lint to lint on all editions (it is not a edition dependent lint).
What am I meant to do as a downstream of a macro crate that hasn't fixed it then? I don't want to be ing a FCW, but there's nothing else I can do to clear this warning from my code. (And that implies that the planned "hard error in 2027" actually means for all editions, not just Edition 2027?)
Allow the lint. Report the issue upstream. Consider switching to an unaffected crate. That's understandable, but until the upstream crate is fixed I don't have a better solution. Note, that it is quite unlikely that this point that the lint will become deny-by-default in Rust 2024. No, if hard-error there is, it would only be for edition 2027 and higher, not below.
Why?
Detecting and ignoring macro-generated code for a lint where possible is the expected behavior of rustc.
Because, in particular for macro-generated code, we can't lint at the source since, well it is only generated when using the proc-macro or . Yes, but we must still emit the warning in macro-generated code, since the goal is to make the lint deny-by-default and then hard-error in a future edition, and without the warn it would go straight to hard-error which is not good.
Is there no ability to enable the lint when in the same crate/workspace but disable it for "foreign" macro-generated spans?
Yes, but can't rely on this. Also, not all macros have tests. The lint is only warn-by-default so it wouldn't break any test yet. If you mean: "don't lint on external macro", that is possible for but not for proc-macro since they are always external. We did an crater run, to evaluate the impact, before merging the lint in We had many cases with derive-macro, most of them (82.2%) where fixable by a , the rest would need manual intervention, the crate in question here was detected, and I reported the issue upstream with the fix that would fix the issue.
that was why I was thinking of trying to reason cross-workspace, but hmm, true. And actually, proc macros are worse: they can , so at least some are going to almost certainly slip through either way.
I would love if we had the ability to do that, but unfortunately doesn't have that information. Workspaces are a Cargo-only concept. :eyes:
I was hoping that we could do something where cargo helps us out here by describing which things we pay attention to, but I am fully prepared to believe that such is not tractable, even if only because no one has figured out if the infra for doing such a thing is even possible.
Yeah, unfortunately there isn't really anything else the compiler can do, it would be great if we could lint at the macro definition but due to the way they work that isn't possible, we are therefore forced to do the second "best" thing and lint at the usage. should be make it clearer that the "macro needs to change". So let's reclassify this issue as not-a-bug but as a discussion. labels -C-bug +C-discussion

Related discussion:
text: .bounds = `impl` may be usable in bounds, etc. from outside the expression, which might e.g. make something constructible that previously wasn't, because it's still on a publicly-visible type .exception = items in an anonymous const item (`const _: () = {"{"} ... {"}"}`) are treated as in the same scope as the anonymous const's declaration .const_anon = use a const-anon item to suppress this lint <ins> .macro_to_change = the {$macro_kind} `{$macro_to_change}` defines the non-local `impl`, and may need to be changed </ins> lint_non_local_definitions_impl_move_help = move the `impl` block outside of this {$body_kind_descr} {$depth ->