Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 7 pull requests #136549

Merged
merged 21 commits into from
Feb 4, 2025
Merged

Rollup of 7 pull requests #136549

merged 21 commits into from
Feb 4, 2025

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

samueltardieu and others added 21 commits January 29, 2025 12:31
This function was only kept for Clippy use. The last use in Clippy was
removed in c9315bc.
This trait doesn't appear to provide any benefit over a simple helper function.
…h, r=flip1995

Remove `LateContext::match_def_path()`

This function was only kept for Clippy use. The last use in Clippy was removed in c9315bc.
Check Sizedness of return type in WF

Still need to clean this up a bit. This should fix rust-lang/trait-system-refactor-initiative#150.

r? lcnr
Allow using named consts in pattern types

This required a refactoring first: I had to stop using `hir::Pat`in `hir::TyKind::Pat` and instead create a separate `TyPat` that has `ConstArg` for range ends instead of `PatExpr`. Within the type system we should be using `ConstArg` for all constants, as otherwise we'd be maintaining two separate const systems that could diverge. The big advantage of this PR is that we now inherit all the rules from const generics and don't have a separate system. While this makes things harder for users (const generic rules wrt what is allowed in those consts), it also means we don't accidentally allow some things like referring to assoc consts or doing math on generic consts.
Fix a couple NLL TLS spans

Some NLL TLS tests show incorrect spans for the end of function. It seems that the `TerminatorKind::Return` source info span can sometimes point at the single character after the end of the function.

Completely changing the span where the terminator is built also changes a bunch of diagnostics: small functions have more code shown unrelated to the errors at hand, wrapping symbols appear and weird-looking arrows point to the end of function, etc. So it seems this is somehow unexpectedly relied upon in making diagnostics look better and their heuristics.

So I just changed it where it matters for these few tests: the diagnostics specialized to conflict errors with thread locals.

r? `@matthewjasper`
Report generic mismatches when calling bodyless trait functions

Don't know if there's an open issue for this. Just happened to notice this when working in that area.

The awkward extra spans added to the diagnostics of some tests (e.g. `trait-with-missing-associated-type-restriction`) is consistent with what happens for normal functions. Should probably be removed since that span doesn't seem to note anything useful.

First and third commit are both cleanups removing some unnecessary work. Second commit has the actual fix.

fixes rust-lang#135124
…ssert, r=lcnr

Remove unnecessary layout assertions for object-safe receivers

The soundness of `DispatchFromDyn` relies on the fact that, like all other built-in marker-like layout traits (e.g. `Sized`, `CoerceUnsized`), the guarantees that they enforce in *generic* code via traits will result in assumptions that we can rely on in codegen.

Specifically, `DispatchFromDyn` ensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds the `Scalar` or `ScalarPair` representation for sized and unsized pointees, respectively.

The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best.

This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161.

Fixes rust-lang#125810
Fixes rust-lang#90110

This PR is an alternative to rust-lang#136195. cc `@adetaylor.` I didn't realize in that PR that the layout checks that were being modified were simply *sanity checks*, rather than being actually necessary for soundness.
mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`

A combination of two loosely-related tweaks that would otherwise conflict with each other:

- `Cx` is a pretty unhelpful type name, especially when jumping between THIR-building and MIR-building while trying to make changes to THIR data structures.

- The `UserAnnotatedTyHelpers` trait doesn't appear to provide any benefit over a simple helper function, and its `tcx()` method is currently completely unnecessary.

No functional change.
@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 4, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Feb 4, 2025

📌 Commit 1b7efa2 has been approved by matthiaskrgr

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 Feb 4, 2025
@bors
Copy link
Contributor

bors commented Feb 4, 2025

⌛ Testing commit 1b7efa2 with merge bef3c3b...

@bors
Copy link
Contributor

bors commented Feb 4, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing bef3c3b to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 4, 2025
@bors bors merged commit bef3c3b into rust-lang:master Feb 4, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Feb 4, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#136242 Remove LateContext::match_def_path() 3e4e6ce8833e419be3d4cef1c91e7776cda0b6d6 (link)
#136274 Check Sizedness of return type in WF 8b1d51f4703a8b60dc3f59301b1917f0b2b3a9a3 (link)
#136284 Allow using named consts in pattern types 4b9ceaf2939db9e348de633e51d973f40c61e5b0 (link)
#136477 Fix a couple NLL TLS spans 35808e6505cd493b5558204498c1aa43a3a82f8e (link)
#136497 Report generic mismatches when calling bodyless trait funct… c99dd81f4504ca8f2b85b898fe479716e1939fc9 (link)
#136520 Remove unnecessary layout assertions for object-safe receiv… 2c194e7ad1cf3bb169a1de09f2fd34cf5bac9cad (link)
#136526 mir_build: Rename thir::cx::Cx to ThirBuildCx and remov… 92821e95ae31e0169ac1da31c276d30eb56a10d9 (link)

previous master: 3f33b30e19

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (bef3c3b): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.3% [0.2%, 0.3%] 7
Improvements ✅
(primary)
-0.3% [-0.3%, -0.2%] 5
Improvements ✅
(secondary)
-0.6% [-0.8%, -0.3%] 5
All ❌✅ (primary) -0.3% [-0.3%, -0.2%] 5

Max RSS (memory usage)

Results (primary -1.4%, secondary -1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

Results (secondary -1.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

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

Bootstrap: 778.717s -> 777.434s (-0.16%)
Artifact size: 328.88 MiB -> 328.75 MiB (-0.04%)

@rustbot rustbot added the perf-regression Performance regression. label Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustdoc-json Area: Rustdoc JSON backend merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. rollup A PR which is a rollup 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants