Skip to content

NFC normalize lifetime identifiers#149192

Merged
bors merged 2 commits intorust-lang:mainfrom
gmorenz:normalize_lifetimes
Dec 14, 2025
Merged

NFC normalize lifetime identifiers#149192
bors merged 2 commits intorust-lang:mainfrom
gmorenz:normalize_lifetimes

Conversation

@gmorenz
Copy link
Contributor

@gmorenz gmorenz commented Nov 21, 2025

Fixes #126759

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 21, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 21, 2025

r? @madsmtm

rustbot has assigned @madsmtm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@jieyouxu
Copy link
Member

jieyouxu commented Dec 2, 2025

This is a observable language change in that previously we didn't accept

struct Foo<'a>(&'a ());
fn foo<'K>(_x: Foo<'K>, _y: Foo<'>) {}
//      ^- latin K               ^- kelvin K
error[E0261]: use of undeclared lifetime name `'K`
 --> src/lib.rs:3:33
  |
3 | fn foo<'K>(_x: Foo<'K>, _y: Foo<'K>) {}
  |                                 ^^ undeclared lifetime
  |
help: consider introducing lifetime `'K` here
  |
3 | fn foo<'K, 'K>(_x: Foo<'K>, _y: Foo<'K>) {}
  |        +++

So when we do NFC-normalize the lifetimes, we are now accepting more code (but is consistent with the original RFC and regular identifiers). This needs a lang FCP, and probably an update to the reference on NFC-normalization.

@rustbot label: +I-lang-nominated

@rustbot rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Dec 2, 2025
@gmorenz
Copy link
Contributor Author

gmorenz commented Dec 2, 2025

I think the reference is actually fine - I'm not sure if something changed since the original bug report or the original bug report was just a generous reading of the current reference as accepting the non-normalizing implementation.

The lifetime syntax page is here, and simply references the lifetime identifiers as either IDENTIFIER_OR_KEYWORD or NON_KEYWORD_IDENTIFIER as defined here which specifies that they should be normalized.

@traviscross traviscross added P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang T-lang Relevant to the language team labels Dec 3, 2025
@traviscross
Copy link
Contributor

We talked about this on the lang call today. We agreed that idents used for lifetimes should work in the same way here as idents in other positions.

@rfcbot fcp merge lang

@rust-rfcbot
Copy link
Collaborator

rust-rfcbot commented Dec 3, 2025

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rust-rfcbot rust-rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Dec 3, 2025
@tmandry
Copy link
Member

tmandry commented Dec 3, 2025

@rfcbot reviewed

@rust-rfcbot rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Dec 3, 2025
@rust-rfcbot
Copy link
Collaborator

🔔 This is now entering its final comment period, as per the review above. 🔔

@traviscross traviscross added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang labels Dec 3, 2025
@scottmcm
Copy link
Member

scottmcm commented Dec 3, 2025

I absolutely think we should always have lifetimes treated like tick-then-ident, so if we're doing NFC for idents then 100% agreed we should do the same for lifetimes.

@rfcbot reviewed

@madsmtm
Copy link
Contributor

madsmtm commented Dec 4, 2025

Possibly perf-sensitive, we're now calling unicode_normalization::is_nfc_quick on every lifetime identifier (not that I really see a way of doing this work faster if it is indeed a regression).

@bors try @rust-timer queue

Implementation looks fine, feel free to r=me when FCP and perf finishes.

@rust-timer

This comment has been minimized.

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Dec 4, 2025
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 4, 2025
@rust-timer

This comment was marked as duplicate.

@rust-bors
Copy link
Contributor

rust-bors bot commented Dec 4, 2025

☀️ Try build successful (CI)
Build commit: 94d5cd8 (94d5cd8975524cac058eb459d5a2c53720210d2b, parent: b1b08cdef5ed3bca71c0d6638fccadc90d2e0ea3)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (94d5cd8): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.1% [0.1%, 0.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.1% [-0.1%, -0.1%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 1.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.0% [1.0%, 1.0%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.0% [1.0%, 1.0%] 1

Cycles

Results (primary -2.8%, secondary 4.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
4.7% [4.7%, 4.7%] 1
Improvements ✅
(primary)
-2.8% [-2.8%, -2.8%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.8% [-2.8%, -2.8%] 1

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 4
Regressions ❌
(secondary)
0.0% [0.0%, 0.1%] 14
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [0.0%, 0.0%] 4

Bootstrap: 467.027s -> 468.583s (0.33%)
Artifact size: 386.67 MiB -> 386.76 MiB (0.02%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 4, 2025
@madsmtm madsmtm added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 13, 2025
@rust-rfcbot rust-rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Dec 13, 2025
@rust-rfcbot
Copy link
Collaborator

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

@madsmtm
Copy link
Contributor

madsmtm commented Dec 13, 2025

@bors r+

I'm unsure if there is a measurable perf regression, or if it's just spurious. In any case, not really something we can do differently.

@bors
Copy link
Collaborator

bors commented Dec 13, 2025

📌 Commit b1cde92 has been approved by madsmtm

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Dec 13, 2025
@gmorenz
Copy link
Contributor Author

gmorenz commented Dec 13, 2025

If there is a perf regression this suggests that the normalization code might be able to be an order of magnitude faster. Which given that we're already running this on all other identifiers - and I'd guess that there are a lot more normal identifiers than lifetime ones - might lead to a fairly sizable improvement.

A way to test if this is worth pursuing would be to run benchmarks with normalization commented out for normal identifiers as well.

@bors
Copy link
Collaborator

bors commented Dec 13, 2025

⌛ Testing commit b1cde92 with merge 2cd4ee6...

@bors
Copy link
Collaborator

bors commented Dec 14, 2025

☀️ Test successful - checks-actions
Approved by: madsmtm
Pushing 2cd4ee6 to main...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 14, 2025
@bors bors merged commit 2cd4ee6 into rust-lang:main Dec 14, 2025
13 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Dec 14, 2025
@github-actions
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 430d829 (parent) -> 2cd4ee6 (this PR)

Test differences

Show 6 test diffs

Stage 1

  • [ui] tests/ui/lexer/ident_normalization.rs: [missing] -> pass (J0)

Stage 2

  • [ui] tests/ui/lexer/ident_normalization.rs: [missing] -> pass (J1)

Additionally, 4 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 2cd4ee6bcf517345dd76d7b102d56b2e873cddbc --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-various-1: 4105.9s -> 6357.6s (+54.8%)
  2. dist-x86_64-apple: 7002.3s -> 8299.8s (+18.5%)
  3. dist-ohos-aarch64: 4731.2s -> 4128.5s (-12.7%)
  4. x86_64-gnu-llvm-21-3: 6244.2s -> 7018.2s (+12.4%)
  5. dist-aarch64-llvm-mingw: 5438.7s -> 6066.3s (+11.5%)
  6. dist-sparcv9-solaris: 4974.8s -> 5495.5s (+10.5%)
  7. x86_64-gnu-llvm-20: 2465.2s -> 2706.4s (+9.8%)
  8. aarch64-msvc-2: 6531.2s -> 6008.5s (-8.0%)
  9. dist-ohos-armv7: 4434.7s -> 4083.5s (-7.9%)
  10. dist-s390x-linux: 5326.2s -> 4929.7s (-7.4%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (2cd4ee6): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.5%, secondary -2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.5% [1.5%, 1.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.5% [-2.5%, -2.5%] 1
All ❌✅ (primary) 1.5% [1.5%, 1.5%] 1

Cycles

Results (secondary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.0% [2.0%, 2.0%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.6% [-3.6%, -3.6%] 1
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 473.205s -> 474.624s (0.30%)
Artifact size: 389.51 MiB -> 389.52 MiB (0.00%)

makai410 pushed a commit to makai410/rust that referenced this pull request Dec 16, 2025
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Mar 7, 2026
Pkgsrc changes:
 * Update version & checksums.
 * Adapt patches to new vendored crates.

This has so far just been verified to build on NetBSD/amd64.

Upstream changes relative to 1.93.1:

Version 1.94.0 (2026-03-05)
==========================

Language
--------
- [Impls and impl items inherit `dead_code` lint level of the
  corresponding traits and trait items]
  (rust-lang/rust#144113)
- [Stabilize additional 29 RISC-V target features including large
  portions of the RVA22U64 / RVA23U64 profiles]
  (rust-lang/rust#145948)
- [Add warn-by-default `unused_visibilities` lint for visibility
  on `const _` declarations]
  (rust-lang/rust#147136)
- [Update to Unicode 17]
  (rust-lang/rust#148321)
- [Avoid incorrect lifetime errors for closures]
  (rust-lang/rust#148329)

Platform Support
----------------
- [Add `riscv64im-unknown-none-elf` as a tier 3 target]
  (rust-lang/rust#148790)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

[platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html

Libraries
---------
- [Relax `T: Ord` bound for some `BinaryHeap<T>` methods.]
  (rust-lang/rust#149408)

Stabilized APIs
---------------
- [`<[T]>::array_windows`]
  (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.array_windows)
- [`<[T]>::element_offset`]
  (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.element_offset)
- [`LazyCell::get`]
  (https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html#method.get)
- [`LazyCell::get_mut`]
  (https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html#method.get_mut)
- [`LazyCell::force_mut`]
  (https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html#method.force_mut)
- [`LazyLock::get`]
  (https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html#method.get)
- [`LazyLock::get_mut`]
  (https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html#method.get_mut)
- [`LazyLock::force_mut`]
  (https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html#method.force_mut)
- [`impl TryFrom<char> for usize`]
  (https://doc.rust-lang.org/stable/std/convert/trait.TryFrom.html#impl-TryFrom%3Cchar%3E-for-usize)
- [`std::iter::Peekable::next_if_map`]
  (https://doc.rust-lang.org/stable/std/iter/struct.Peekable.html#method.next_if_map)
- [`std::iter::Peekable::next_if_map_mut`]
  (https://doc.rust-lang.org/stable/std/iter/struct.Peekable.html#method.next_if_map_mut)
- [x86 `avx512fp16` intrinsics]
  (rust-lang/rust#127213)
  (excluding those that depend directly on the unstable `f16` type)
- [AArch64 NEON fp16 intrinsics]
  (rust-lang/rust#136306)
  (excluding those that depend directly on the unstable `f16` type)
- [`f32::consts::EULER_GAMMA`]
  (https://doc.rust-lang.org/stable/std/f32/consts/constant.EULER_GAMMA.html)
- [`f64::consts::EULER_GAMMA`]
  (https://doc.rust-lang.org/stable/std/f64/consts/constant.EULER_GAMMA.html)
- [`f32::consts::GOLDEN_RATIO`]
  (https://doc.rust-lang.org/stable/std/f32/consts/constant.GOLDEN_RATIO.html)
- [`f64::consts::GOLDEN_RATIO`]
  (https://doc.rust-lang.org/stable/std/f64/consts/constant.GOLDEN_RATIO.html)

These previously stable APIs are now stable in const contexts:

- [`f32::mul_add`]
  (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.mul_add)
- [`f64::mul_add`]
  (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.mul_add)

Cargo
-----
- Stabilize the config include key. The top-level include config
  key allows loading additional config files, enabling better
  organization, sharing, and management of Cargo configurations
  across projects and environments. [docs]
  (https://doc.rust-lang.org/nightly/cargo/reference/config.html#including-extra-configuration-files)
  [#16284] (rust-lang/cargo#16284)
- Stabilize the pubtime field in registry index. This records when
  a crate version was published and enables time-based dependency
  resolution in the future. Note that crates.io will gradually backfill
  existing packages when a new version is published. Not all crates
  have pubtime yet. [#16369]
  (rust-lang/cargo#16369) [#16372]
  (rust-lang/cargo#16372)
- Cargo now parses [TOML v1.1](https://toml.io/en/v1.1.0) for
  manifests and configuration files. Note that using these features
  in Cargo.toml will raise your development MSRV, but the published
  manifest remains compatible with older parsers. [#16415]
  (rust-lang/cargo#16415)
- [Make `CARGO_BIN_EXE_<crate>` available at runtime ]
  (rust-lang/cargo#16421)

Compatibility Notes
-------------------
- [Forbid freely casting lifetime bounds of `dyn`-types]
  (rust-lang/rust#136776)
- [Make closure capturing have consistent and correct behaviour around patterns]
  (rust-lang/rust#138961)
  Some finer details of how precise closure captures get affected
  by pattern matching have been changed. In some cases, this can
  cause a non-move closure that was previously capturing an entire
  variable by move, to now capture only part of that variable by
  move, and other parts by borrow. This can cause the borrow checker
  to complain where it previously didn't, or cause `Drop` to run
  at a different point in time.
- [Standard library macros are now imported via prelude, not via injected `
  #[macro_use]`] (rust-lang/rust#139493)
  This will raise an error if macros of the same name are glob
  imported.  For example if a crate defines their own `matches`
  macro and then glob imports that, it's now ambiguous whether the
  custom or standard library `matches` is meant and an explicit
  import of the name is required to resolve the ambiguity.  One
  exception is `core::panic` and `std::panic`, if their import is
  ambiguous a new warning ([`ambiguous_panic_imports`]
  (rust-lang/rust#147319)) is raised.
  This may raise a new warning ([`ambiguous_panic_imports`]
  (rust-lang/rust#147319)) on `#![no_std]`
  code glob importing the std crate.  Both `core::panic!` and
  `std::panic!` are then in scope and which is used is ambiguous.
- [Don't strip shebang in expression-context `include!(…)`s]
  (rust-lang/rust#146377)
  This can cause previously working includes to no longer compile
  if they included files which started with a shebang.
- [Ambiguous glob reexports are now also visible cross-crate]
  (rust-lang/rust#147984)
  This unifies behavior between local and cross-crate errors on
  these exports, which may introduce new ambiguity errors.
- [Don't normalize where-clauses before checking well-formedness]
  (rust-lang/rust#148477)
- [Introduce a future compatibility warning on codegen attributes
  on body-free trait methods]
  (rust-lang/rust#148756) These attributes
  currently have no effect in this position.
- [On Windows `std::time::SystemTime::checked_sub_duration` will
  return `None` for times before the Windows epoch (1/1/1601)]
  (rust-lang/rust#148825)
- [Lifetime identifiers such as `'a` are now NFC normalized]
  (rust-lang/rust#149192).
- [Overhaul filename handling for cross-compiler consistency]
  (rust-lang/rust#149709)
  Any paths emitted by compiler now always respect the relative-ness
  of the paths and `--remap-path-prefix` given originally.  One
  side-effect of this change is that paths emitted for local crates
  in Cargo (path dependencies and workspace members) are no longer
  absolute but relative when emitted as part of a diagnostic in a
  downstream crate.

Internal Changes
----------------

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

- [Switch to `annotate-snippets` for error emission]
  (rust-lang/rust#150032)
  This should preserve mostly the same outputs in rustc error messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team to-announce Announce this issue on triage meeting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NFC normalisation of lifetimes and labels

10 participants