Rename some Rust 2021 lints to better names

[rylev]

Based on conversation in #85894.

Rename a bunch of Rust 2021 related lints:

Lints that are officially renamed because they are already in beta or stable:

• disjoint_capture_migration => rust_2021_incompatible_closure_captures
• or_patterns_back_compat => rust_2021_incompatible_or_patterns
• non_fmt_panic => non_fmt_panics

Lints that are renamed but don't require any back -compat work since they aren't yet in stable:

• future_prelude_collision => rust_2021_prelude_collisions
• reserved_prefix => rust_2021_token_prefixes

Lints that have been discussed but that I did not rename:

• non_fmt_panic and bare_trait_object: is making this plural worth the headache we might cause users?
• array_into_iter: I'm unsure of a good name and whether bothering users with a name change is worth it.

r? @nikomatsakis

[m-ou-se]

• bare_trait_object: is making this plural worth the headache we might cause users?

Apparently, yes:

$ rustc -Dbare_trait_object /dev/null
warning: lint `bare_trait_object` has been renamed to `bare_trait_objects`

(Seems like this already happened a while ago, and I just missed the s in my overview of the edition lints. ^^)

[m-ou-se]

Nice!

I'm only wondering if reserved_prefixes is the right name. If we add f"" or z"" or k#yeet later in Rust 2021, then these aren't really 'reserved' prefixes. Just prefixes that have a meaning in Rust 2021 and not before.

Maybe rust_2021_incompatible_prefix or just rust_2021_prefix? Or something. Not sure.

[petrochenkov]

reserved_prefixes -> reserved_token_prefixes perhaps?
"Prefix" alone is a very generic word, it's not clear what it refers to without having the specific context of #85359.

[camsteffen]

reserved_prefixes -> future_prefixes

To me reserved_prefixes sounds like "you are using a reserved prefix" rather than "this will be parsed as a prefix in the future".

Edit: or future_prefix_syntax

[rylev]

Suggestions (from above and from me):

• rust_2021_incompatible_prefix
• rust_2021_prefix
• reserved_token_prefixes
• future_prefixes
• future_prefix_syntax
• future_possible_prefix

I'm sympathetic to @petrochenkov's concern about "prefix" being pretty generic, but I do worry that "token_prefix" is too jargon filled.

Here's a Zulip thread to bikeshed.

[petrochenkov]

but I do worry that "token_prefix" is too jargon filled

"Token" is a pretty central terminology for the proc macro API which is stable and public.

[nikomatsakis]

I don't think it's worth stressing too much about "prefixes" vs "token prefixes" -- isn't this an "allow by default" lint? Few people will ever name it explicitly. I do like "rust_2021_incompatible" instead of "reserved". I think that's a good convention for "allow by default" lints.

[nikomatsakis]

@rylev I guess your thinking with "rust_2021_token_prefixes" is that this only warns on things that became a prefix in Rust 2021 (e.g., f"foo") but not things like r"xx" which already were a recognized prefix?

That makes sense to me, I can run live with it.

[rylev]

I was previously in favor of rust_2021_token_prefixes. I believe it to be both descriptive of what type of prefixes and clear that rust_2021 implied that the prefixes used in Rust 2021 but not before.

@m-ou-se had a counter argument though:

i think a key part that's easily missed is that all of these new edition lints are for Rust 2015/2018 and warn about things that would work differently if the code would be interpreted Rust 2021. so if you deny() that, you deny things that are incompatible with the new edition, even though it's currently not yet interpreted that way. so the prefix warning warns about identifiers that will no longer be parsed/tokenized as identifiers when parsed in Rust 2021. these lints do not run in Rust 2021 code. deny(rust_2021_prefixes) makes it sound like that'd deny f"" in Rust 2021. but there it's just a syntax error or a format string. instead, it denies f"" (two tokens) in Rust 2015/2018, because that syntax is changing and incompatible with Rust 2021.

I'm unsure that I agree with the argument "deny(rust_2021_prefixes) makes it sound like that'd deny f"" in Rust 2021", but as @danielhenrymantilla mentioned, there's no real penalty for being verbose, but there could be for being too terse.

With this in mind, @m-ou-se suggested rust_2021_prefix_incompatible_syntax. This is now the one I favor as well although I think rust_2021_prefixes_incompatible_syntax (i.e., prefixes instead of prefix) could be even more understandable.

[rylev]

@nikomatsakis the two remaining questions:

• What should we rename rust_2021_token_prefixes to if anything? My current favorite is rust_2021_prefixes_incompatible_syntax
• Shall we rename array_into_iter even if it's already quite widely used in the ecosystem?

[nikomatsakis]

What should we rename rust_2021_token_prefixes to if anything? My current favorite is rust_2021_prefixes_incompatible_syntax

That works for me.

Shall we rename array_into_iter even if it's already quite widely used in the ecosystem?

As a rename? This one is (iirc) warn by default, so the name is more likely to be something users are exposed to. Still, I think it's name is not wrong -- it just fails to describe the edition-dependent nature of it? I think we can leave it personally.

[m-ou-se]

Leaving array_into_iter seems fine to me. It used to warn about all cases of array.into_iter, but since the edition hack it only warns about array.into_iter in rust 2015 and 2018. Adding 2021 into the name wouldn't make as much sense as for some of the other lints, as it is warning about the hack in pre-2021 code, which doesn't exist in rust 2021. I guess it could be array_into_iter_by_ref or something, but probably not worth it.

[bors]

☔ The latest upstream changes (presumably #86231) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

@bors delegate+

[bors]

✌️ @rylev can now approve this pull request

[nikomatsakis]

@bors r+

[bors]

📌 Commit d4e384b has been approved by nikomatsakis