Resolver cm token by LorrensP-2158466 · Pull Request #160345 · rust-lang/rust

LorrensP-2158466 · 2026-08-01T15:50:01Z

part of #158845
follow up of #160271 (first commit of this pr)

Introduces a CmToken obtainable only through a &mut Resolver. Which allows *_with_token methods to be used in CmCell and CmRefCell mutating functions.

Also changes CmRefCell::borrow to return a CmRef bassed on resolver.assert_speculative, a borrow_with_token is also introduced.

r? @petrochenkov

… the underlying `RefCell`

LorrensP-2158466 · 2026-08-01T18:52:16Z

Ah, one extra thing. The *_with_token methods are not usable in places like this:

// self is &mut Resolver
for _ in &self.iterable_field {
    self.resolution().borrow(self.cm_token()); 
}

because the iterator is shared on the resolver field, doing self.cm_token() is not possible, even if we have a mutable resolver. There isn't really a way to do this safely with the current borrow checker.

mejrs · 2026-08-01T21:52:10Z

@bors delegate try

rust-bors · 2026-08-01T21:52:12Z

✌️ @LorrensP-2158466, you can now perform try builds on this pull request!

You can now post @bors try to start a try build.

LorrensP-2158466 · 2026-08-01T21:59:50Z

@bors try @rust-timer queue

Resolver cm token

mejrs · 2026-08-01T22:02:08Z

@rust-timer queue

rust-bors · 2026-08-02T00:08:41Z

☀️ Try build successful (CI)
Build commit: 358e11b (358e11b32135d04ea62b279b8125feaff44464a7)
Base parent: 73dc916 (73dc9167f1cd099e525c9ade2e068d1907b78564)

rust-timer · 2026-08-02T00:50:58Z

Finished benchmarking commit (358e11b): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.3%	[0.2%, 0.5%]	16
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -0.6%, secondary -2.7%)

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

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.5%]	3
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-3.7%	[-3.7%, -3.7%]	1
Improvements ✅ (secondary)	-6.2%	[-6.2%, -6.2%]	1
All ❌✅ (primary)	-0.6%	[-3.7%, 0.5%]	4

Cycles

Results (primary 0.1%, secondary 2.4%)

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

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.4%, 2.0%]	7
Regressions ❌ (secondary)	4.4%	[0.5%, 15.4%]	9
Improvements ✅ (primary)	-0.6%	[-1.0%, -0.4%]	6
Improvements ✅ (secondary)	-1.1%	[-2.3%, -0.5%]	5
All ❌✅ (primary)	0.1%	[-1.0%, 2.0%]	13

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.553s -> 490.99s (0.09%)
Artifact size: 390.33 MiB -> 390.43 MiB (0.03%)

…mRef::deref`

LorrensP-2158466 · 2026-08-02T09:27:57Z

It's only unused-warnings, but I am curious what happens when we do our own borrow counting, allowing use to remove the match in CmRef::borrow.

rust-log-analyzer · 2026-08-02T09:34:08Z

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

checking C++ file formatting
spellchecking files
building external tool typos from package typos-cli@1.38.1
finished building tool typos
error: `guarentee` should be `guarantee`
     ╭▸ compiler/rustc_resolve/src/lib.rs:3048:25
     │
3048 │         /// Caller must guarentee that we are not in speculative resolution
     ╰╴                        ━━━━━━━━━
error: `guarentees` should be `guarantees`
     ╭▸ compiler/rustc_resolve/src/lib.rs:3074:40
     │
3074 │             // SAFETY: the given token guarentees us we are not in speculative resolution.
     ╰╴                                       ━━━━━━━━━━
error: `guarentee` should be `guarantee`
     ╭▸ compiler/rustc_resolve/src/lib.rs:3080:25
     │
3080 │         /// Caller must guarentee that we are not in speculative resolution
     ╰╴                        ━━━━━━━━━
error: `guarentees` should be `guarantees`
     ╭▸ compiler/rustc_resolve/src/lib.rs:3095:30
     │
3095 │             // SAFETY: token guarentees us that we are not in speculative resolution.
     ╰╴                             ━━━━━━━━━━
rerun with `--bless` to fix typos: `./x.py test tidy --extra-checks=spellcheck --bless`
tidy [extra_checks:spellcheck]: checks with external tool 'typos' failed
tidy [extra_checks:spellcheck]: FAIL
yarn install v1.22.22
warning package.json: No license field
warning ../../package.json: License should be a valid SPDX license expression
warning No license field
[1/4] Resolving packages...
---
Running eslint on rustdoc JS files
info: ES-Check: checking 7 files...
info: ✓ ES-Check passed! All files are ES10 compatible.
typechecking javascript files
tidy: The following check failed: extra_checks:spellcheck
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Currently active steps:
test::Tidy {  } at src/bootstrap/src/core/build_steps/test.rs:1606
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/checkout --cargo-path=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/checkout/obj/build --concurrency=4 --npm-path=/node/bin/yarn --ci=true --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1684:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:02:43
  local time: Sun Aug  2 09:33:55 UTC 2026
  network time: Sun, 02 Aug 2026 09:33:55 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

mejrs · 2026-08-02T09:47:32Z

@bors try @rust-timer queue

Resolver cm token

rust-bors · 2026-08-02T11:56:41Z

☀️ Try build successful (CI)
Build commit: 5ea1493 (5ea14939f6d4c3e7a2d26981ec58268804b71269)
Base parent: 73dc916 (73dc9167f1cd099e525c9ade2e068d1907b78564)

petrochenkov · 2026-08-02T12:03:58Z

I wouldn't want to introduce a lot of unsafe code an copypaste of RefCell internals for <0.5% benefits on unused-warnings.
The benchmarks in https://perf.rust-lang.org/compare.html?start=73dc9167f1cd099e525c9ade2e068d1907b78564&end=358e11b32135d04ea62b279b8125feaff44464a7&stat=instructions:u already looks good enough.

I'll review after the second benchmark run finishes and the manual ref counting commit is removed.
@rustbot author

rustbot · 2026-08-02T12:04:02Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

LorrensP-2158466 · 2026-08-02T12:05:29Z

I wouldn't want to introduce a lot of unsafe code an copypaste of RefCell internals for <0.5% benefits on unused-warnings.

Understandable, I was mostly curious :).

petrochenkov · 2026-08-02T12:13:11Z

If we have methods taking a token, then panicking methods not taking a token are not necessary anymore (*).
From a mutable resolver we can obtain a token without a dynamic check, from an immutable resolver we can obtain a token with a dynamic check.

impl Resolver {
  fn token1(&mut self) -> CmToken { debug_assert!(!self.assert_speculative); CmToken { ... } }
  fn token2(&self) -> CmToken { assert!(!self.assert_speculative); CmToken { ... } }
}

(*) Unless there are borrow checker issues like #160345 (comment), then we can have more unsafe methods taking a boolean or something.

rust-timer · 2026-08-02T13:16:28Z

Finished benchmarking commit (5ea1493): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary 0.8%, secondary 0.5%)

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

	mean	range	count
Regressions ❌ (primary)	1.3%	[0.4%, 6.9%]	9
Regressions ❌ (secondary)	0.5%	[0.4%, 1.0%]	14
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[-3.4%, 6.9%]	10

Cycles

Results (primary 0.3%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.4%, 1.0%]	7
Regressions ❌ (secondary)	1.5%	[0.5%, 5.3%]	7
Improvements ✅ (primary)	-0.7%	[-0.9%, -0.5%]	3
Improvements ✅ (secondary)	-2.0%	[-3.9%, -0.9%]	5
All ❌✅ (primary)	0.3%	[-0.9%, 1.0%]	10

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.553s -> 489.78s (-0.16%)
Artifact size: 390.33 MiB -> 390.45 MiB (0.03%)

LorrensP-2158466 added 3 commits August 1, 2026 15:22

implement CmRef for CmRefCell, having 2 different borrow types of…

9890f66

… the underlying `RefCell`

introduce a token for Cm(Ref)Cell for unchecked mutations

f3de5d9

CmRefCell::borrow now returns CmRef based on assert_speculative

5475d00

rustbot assigned petrochenkov Aug 1, 2026

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 Aug 1, 2026