(More) consistently use "region" terminology in rustc_middle

[WaffleLapkin]

I started with GenericArg and then renamed some other stuff I saw. It looks like in the later compiler stages we almost always use "region" as a term instead of "lifetime". I've renamed some weird occurrences of lifetimes in these stages:

• GenericArgKind::{Lifetime => Region} (this one literally hold ty::Region as a field...)
• GenericParamDefKind::{Lifetime => Region}
• tcx.{lifetimes => regions}
  • CommonLifetimes => CommonRegions
  • CommonRegions::{re_erased => erased, re_vars => vars, re_late_bounds => late_bounds}
    • re_static was left as-is (static is a keyword...)

@bors rollup=never p=1

[rustbot]

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in need_type_info.rs

cc @lcnr

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[compiler-errors]

Hm, I think this may need further discussion.

I don't think, for example, we should call them GenericParamDefKind:: Region. It feels like that type is right at the threshold of the distinction we make between calling them "lifetimes" in user-facing positions and "regions" for internal purposes. Also, while I personally prefer the name region, I'm somewhat suspicious that it's not universally preferred over lifetime, and it's not necessarily clear that we should be renaming things from lifetime=>region or region=>lifetime...

[lcnr]

cc https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/naming.20bikeshedding it doesn't seem like there is consensus that we go with region over lifetime 🤷

[WaffleLapkin]

My point was that consistency matters and in later compilation stages we almost exclusively use "region" as the term, so changing few places where we don't makes sense. With GenericArg for example, it literally holds ty::Region, so it's weird to call the variant Lifetime...

I think even if we eventually end up renaming "region" to something else, it would be a much bigger change and this does not conflict with that (if anything by making it more consistent, the rename would be easier to do).

(I also just like the "region", so there is that)

I don't think, for example, we should call them GenericParamDefKind::Region. It feels like that type is right at the threshold of the distinction we make between calling them "lifetimes" in user-facing positions and "regions" for internal purposes.

The good thing is — I can just drop commits that rename GenericParamDefKind::.... Maybe I went a little bit too far with it...

[bors]

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

[apiraino]

hello, checking progress - any actionable here yet or is the discussion still ongoing? Does it need to be nominated for a {compiler|lang} meeting? thanks!

[WaffleLapkin]

I've opened an MCP for this change: rust-lang/compiler-team#634

(as a side-note I've also added a S-waiting-on-MCP Status: PR has a compiler MCP and is waiting for the compiler MCP to complete. label)

[WaffleLapkin]

The MCP was closed and this has a ton of conflicts, so — closing.

As a remark, I still like the region name better, but it doesn't seem like a lot of people agree with me. Hope someone will work on #110254, so that we at least use something consistently.