`non_local_definitions` lint is unhappy with multiple nested anonymous constants

[clarfonthey]

I tried this code:

struct Test;
const _: () = {
    const _: () = {
        impl Default for Test {
            fn default() -> Test {
                Test
            }
        }
    };
};

This should be completely okay, since the impl is only nested within anonymous constant blocks.

Instead, you get this backwards-compatibility warning:

warning: non-local `impl` definition, `impl` blocks should be written at the same level as their item
 --> src/lib.rs:5:9
  |
4 |     const _: () = {
  |     ----------- move the `impl` block outside of this constant `_` and up 2 bodies
5 |         impl Default for Test {
  |         ^^^^^-------^^^^^----
  |              |           |
  |              |           `Test` is not local
  |              `Default` is not local
  |
  = note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl`
  = note: items in an anonymous const item (`const _: () = { ... }`) are treated as in the same scope as the anonymous const's declaration for the purpose of this lint
  = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
  = note: `#[warn(non_local_definitions)]` on by default

Meta

rustc --version --verbose:

rustc 1.83.0-nightly (6f4ae0f34 2024-10-08)
binary: rustc
commit-hash: 6f4ae0f34503601e54680a137c1db0b81b56cc3d
commit-date: 2024-10-08
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.1

This is currently affecting the bevy_reflect crate, which has a few instances of doubly-nested anonymous constants generated by macros. Particularly, the impl_type_path! macro nests its result in an anonymous constant, and the impl_reflect_for_atomic! calls this macro inside an anonymous constant. The anonymous constants exist to allow local imports without affecting the larger scope.

[jieyouxu]

cc @Urgau as you might know more about this.

[Urgau]

Considering const _ : () as "transparent" is mainly a compatibility enhancement, so considering multiple consecutive of them as "transparent" would go in this direction, even though I'm not too thrilled about the general direction.

cc @traviscross (since this is a lang issue)
@rustbot label +T-lang

[traviscross]

I'd expect these to be recursively transparent, yes. That is, I would not expect the lint to fire here.

[clarfonthey]

Yeah, I think that it would be extremely confusing to only consider a single layer of these, even though I understand why the code currently does this.

To me, it should either be all recursively or none. I think it's fair to say that the presence of recursive nesting makes it worth reconsidering whether they should be added as an exception to the lint, but I don't think that the one-layer option should be considered, especially considering how as the lint is worded, that isn't apparent.