Skip to content

Conversation

@WaffleLapkin
Copy link
Member

... and minor cleanup.

r? lcnr

@WaffleLapkin WaffleLapkin added the F-never_type `#![feature(never_type)]` label Nov 12, 2025
@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 12, 2025
@rust-log-analyzer

This comment has been minimized.

@WaffleLapkin
Copy link
Member Author

I have really low confidence in the never type tests, IMO they require a major refactoring, as a lot of them are based on outdated ideas and features...

@rust-log-analyzer

This comment has been minimized.

@jackh726
Copy link
Member

For the tests, I would expect us to have revisions for edition 2021 and edition 2024 (for the different fallbacks)

@WaffleLapkin
Copy link
Member Author

@jackh726 I'm not sure 2021vs2015 is relevant. But either way, yes, I agree that we should have tests for both current fallback behaviors based on the edition. I'll make a followup which cleans up the tests, wanna make sure that we have relevant and comprehensive tests.

@rust-log-analyzer

This comment has been minimized.

Comment on lines 56 to 58
// phase of fallback. This means that we only replace
// inference variables with their underlying opaque types as a
// last resort.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

existing, but I do not understand that comment?

Do you understand what this wants to say. It feels like this is a general "if fallback occurred, previously stalled goals may make progress again".

I really don't see how there's anything specific to opaques here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get it either .-.

the example below is supposed to explain this, but I still don't get it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, want to rip this out and replace it with

if fallback occurred, previously stalled goals may make progress again

even if this comment was somehow relevant, given that we both don't get what it means, I don't think it does us any good

});
let unit_obligation = obligation.with(tcx, predicate);
if self.predicate_may_hold(&unit_obligation) {
// FIXME: make a new issue for this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate on that FIXME? it feels unactionable for anyone who isn't you right now... or maybe just do that if you can xd

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I opened #148922 and linked it from here. I tried my best to write a good explanation, but it's just confusing :(

@@ -1,9 +1,8 @@
//@ revisions: nofallback fallback
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

want to rename the revisions to "unit_fallback never_fallback"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a follow up

fallback_to(self.tcx.types.unit);
}
DivergingFallbackBehavior::ContextDependent => {
if found_infer_var_info.self_in_trait && found_infer_var_info.output {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

found_infer_var_info is dead code now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean InferVarInfo? Yes, it is. Removed.

@lcnr lcnr added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 13, 2025
@jackh726
Copy link
Member

@jackh726 I'm not sure 2021vs2015 is relevant. But either way, yes, I agree that we should have tests for both current fallback behaviors based on the edition. I'll make a followup which cleans up the tests, wanna make sure that we have relevant and comprehensive tests.

I don't think we need to worry about 2015, just 2024 vs 2021 since that highlights the difference in fallback behavior.

@WaffleLapkin
Copy link
Member Author

@rustbot review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 13, 2025
@lcnr
Copy link
Contributor

lcnr commented Nov 16, 2025

@bors try @rust-timer queue

@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 Nov 16, 2025
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 16, 2025
@rust-bors
Copy link

rust-bors bot commented Nov 16, 2025

☀️ Try build successful (CI)
Build commit: 2fb4a7a (2fb4a7a100a7d913c8233bdd63e268de1930a7fc, parent: 67c4cf395f243afcb973dacdd39b16895c9ad295)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (2fb4a7a): comparison URL.

Overall result: ✅ 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
Improvements ✅
(primary)
-0.4% [-3.0%, -0.1%] 36
Improvements ✅
(secondary)
-0.2% [-0.5%, -0.1%] 35
All ❌✅ (primary) -0.4% [-3.0%, -0.1%] 36

Max RSS (memory usage)

Results (primary -1.1%)

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)
- - 0
Improvements ✅
(primary)
-1.1% [-1.3%, -1.0%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.1% [-1.3%, -1.0%] 2

Cycles

Results (secondary 3.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)
3.8% [3.7%, 4.0%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 473.917s -> 472.516s (-0.30%)
Artifact size: 388.65 MiB -> 388.63 MiB (-0.00%)

@lcnr
Copy link
Contributor

lcnr commented Nov 17, 2025

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 17, 2025
The code supporting it is extremely confusing. At the same time, we have
no plans to use this scheme, so there is no value in supporting it.
the only diagnostic that was using this field specifically сares for the
never type fallback, not the integer fallback.
I think in this case the early return is harder to read than just an if.
"if fallback hasn't occured we don't do..."
One is about context dependant case which I removed a few commits back,
the other neither me nor lcnr could understand, soooo :upsidedown_smile:
... now that it's always the same for a certain crate
@rustbot
Copy link
Collaborator

rustbot commented Nov 27, 2025

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@WaffleLapkin WaffleLapkin requested a review from lcnr November 27, 2025 21:50
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 27, 2025
@lcnr
Copy link
Contributor

lcnr commented Nov 28, 2025

@bors r+ rollup=never

@bors
Copy link
Collaborator

bors commented Nov 28, 2025

📌 Commit 37ecc8e has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 28, 2025
@bors
Copy link
Collaborator

bors commented Nov 28, 2025

⌛ Testing commit 37ecc8e with merge d645a4c...

@bors
Copy link
Collaborator

bors commented Nov 28, 2025

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing d645a4c to main...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 28, 2025
@bors bors merged commit d645a4c into rust-lang:main Nov 28, 2025
12 checks passed
@rustbot rustbot added this to the 1.93.0 milestone Nov 28, 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 88bd39b (parent) -> d645a4c (this PR)

Test differences

Show 29 test diffs

Stage 1

  • [ui] tests/ui/never_type/diverging-fallback-control-flow.rs#fallback: pass -> [missing] (J0)
  • [ui] tests/ui/never_type/diverging-fallback-control-flow.rs#nofallback: pass -> [missing] (J0)
  • [ui] tests/ui/never_type/feature-gate-never_type_fallback.rs: pass -> [missing] (J0)

Stage 2

  • [ui] tests/ui/never_type/diverging-fallback-control-flow.rs#fallback: pass -> [missing] (J1)
  • [ui] tests/ui/never_type/diverging-fallback-control-flow.rs#nofallback: pass -> [missing] (J1)
  • [ui] tests/ui/never_type/feature-gate-never_type_fallback.rs: pass -> [missing] (J1)

Additionally, 23 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 d645a4c9c563b80048ce5f32845e754a67f11efa --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-aarch64-apple: 5953.0s -> 8503.9s (+42.9%)
  2. dist-x86_64-apple: 6037.7s -> 7909.2s (+31.0%)
  3. x86_64-gnu-llvm-20: 2435.8s -> 2862.0s (+17.5%)
  4. dist-i586-gnu-i586-i686-musl: 4883.9s -> 5617.4s (+15.0%)
  5. x86_64-gnu-gcc: 3038.8s -> 3454.0s (+13.7%)
  6. x86_64-gnu-tools: 3286.7s -> 3734.0s (+13.6%)
  7. pr-check-1: 1644.1s -> 1859.6s (+13.1%)
  8. i686-gnu-1: 7396.0s -> 8157.6s (+10.3%)
  9. x86_64-gnu-llvm-21-1: 3161.5s -> 3480.5s (+10.1%)
  10. armhf-gnu: 4887.3s -> 5371.1s (+9.9%)
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.

@WaffleLapkin WaffleLapkin deleted the never-simplifications branch November 28, 2025 13:33
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (d645a4c): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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
Improvements ✅
(primary)
-0.3% [-0.4%, -0.1%] 38
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.1%] 40
All ❌✅ (primary) -0.3% [-0.4%, -0.1%] 38

Max RSS (memory usage)

Results (primary 2.0%, secondary 1.2%)

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

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

Cycles

Results (secondary -3.4%)

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)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.4% [-3.4%, -3.4%] 1
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 472.29s -> 473.697s (0.30%)
Artifact size: 386.94 MiB -> 386.90 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

F-never_type `#![feature(never_type)]` 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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants