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 8 pull requests #120089

Merged
merged 22 commits into from
Jan 18, 2024
Merged

Rollup of 8 pull requests #120089

merged 22 commits into from
Jan 18, 2024

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

nnethercote and others added 22 commits January 12, 2024 16:19
By making it an `EscapeError` instead of a `LitError`. This makes it
like the other errors produced when checking string literals contents,
e.g. for invalid escape sequences or bare CR chars.

NOTE: this means these errors are issued earlier, before expansion,
which changes behaviour. It will be possible to move the check back to
the later point if desired. If that happens, it's likely that all the
string literal contents checks will be delayed together.

One nice thing about this: the old approach had some code in
`report_lit_error` to calculate the span of the nul char from a range.
This code used a hardwired `+2` to account for the `c"` at the start of
a C string literal, but this should have changed to a `+3` for raw C
string literals to account for the `cr"`, which meant that the caret in
`cr"` nul error messages was one short of where it should have been. The
new approach doesn't need any of this and avoids the off-by-one error.
Simplify the `run` macro to avoid sometimes unnecessary dependency
on `TyCtxt`. Instead, users can use the new internal method `tcx()`.
Additionally, extend the macro to accept closures that may capture
variables.

These are non-backward compatible changes, but they only affect
internal APIs which are provided today as helper functions until we
have a stable API to start the compiler.
I added `tcx` argument to `internal` to force 'tcx to be the same
lifetime as TyCtxt. The only other solution I could think is to change
this function to be `unsafe`.
- Move fix to a separate PR
…etrochenkov

Detect `NulInCStr` error earlier.

By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars.

NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together.

One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error.

r? ```@fee1-dead```
…li-obk

Make tcx optional from StableMIR run macro and extend it to accept closures

Change `run` macro to avoid sometimes unnecessary dependency on `TyCtxt`, and introduce `run_with_tcx` to capture use cases where `tcx` is required. Additionally, extend both macros to accept closures that may capture variables.

I've also modified the `internal()` method to make it safer, by accepting the type context to force the `'tcx` lifetime to match the context lifetime.

These are non-backward compatible changes, but they only affect internal APIs which are provided today as helper functions until we have a stable API to start the compiler.
Add `PatKind::Err` to AST/HIR

rust-lang#116715 added `thir::PatKind::Error`; this PR adds `hir::PatKind::Err` and `ast::PatKind::Err` (see rust-lang#118625 (comment).)

---

``@rustbot`` label +A-patterns
r? WaffleLapkin
…ures, r=oli-obk

Move async closure parameters into the resultant closure's future eagerly

Move async closure parameters into the closure's resultant future eagerly.

Before, we used to desugar `async |p1, p2, ..| { body }` as `|p1, p2, ..| { || async { body } }`. Now, we desugar the above like `|p1, p2, ..| { async move { let p1 = p1; let p2 = p2; ... body } }`. This mirrors the same desugaring that `async fn` does with its parameter types, and the compiler literally uses the same code via a shared helper function.

This removes the necessity for E0708, since now expressions like `async |x: i32| { x }` will not give you confusing borrow errors.

This does *not* fix the case where async closures have self-borrows. This will come with a general implementation of async closures, which is still in the works.

r? oli-obk
…rrors

don't store const var origins for known vars

r? types
Don't create a separate "basename" when naming and opening a MIR dump file

These functions were split up by rust-lang#77080, in order to support passing the dump file's “basename” (filename without extension) to the implementation of `-Zdump-mir-spanview`, so that it could be used as a page title.

That flag has since been removed (rust-lang#119566), so now there's no particular reason for this code to handle the basename separately from the filename or full path.

This PR therefore restores things to (roughly) how they were before rust-lang#77080.
…r=compiler-errors

Don't ICE when deducing future output if other errors already occurred

The situation can't really happen outside of erroneous code. What was interesting is that it ICEd before emitting any other diagnostics. This was because the other errors were silenced due to cycle_delay_bug cycle errors.

r? ```@compiler-errors```

fixes rust-lang#119890
…cations, r=fmease

Remove spastorino from users_on_vacation
@rustbot rustbot added A-meta Area: Issues about the rust-lang/rust repository. 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 Jan 18, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Jan 18, 2024

📌 Commit 054a435 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 18, 2024
@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 Jan 18, 2024
@bors
Copy link
Contributor

bors commented Jan 18, 2024

⌛ Testing commit 054a435 with merge 377cbb6...

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 18, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#119172 (Detect `NulInCStr` error earlier.)
 - rust-lang#119833 (Make tcx optional from StableMIR run macro and extend it to accept closures)
 - rust-lang#119967 (Add `PatKind::Err` to AST/HIR)
 - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly)
 - rust-lang#120021 (don't store const var origins for known vars)
 - rust-lang#120038 (Don't create a separate "basename" when naming and opening a MIR dump file)
 - rust-lang#120057 (Don't ICE when deducing future output if other errors already occurred)
 - rust-lang#120073 (Remove spastorino from users_on_vacation)

r? `@ghost`
`@rustbot` modify labels: rollup
@matthiaskrgr
Copy link
Member Author

@bors r-

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 18, 2024
@matthiaskrgr matthiaskrgr reopened this Jan 18, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+

@bors
Copy link
Contributor

bors commented Jan 18, 2024

📌 Commit 054a435 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 18, 2024
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

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

@bors
Copy link
Contributor

bors commented Jan 18, 2024

⌛ Testing commit 054a435 with merge 8424f8e...

@bors
Copy link
Contributor

bors commented Jan 18, 2024

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 18, 2024
@bors bors merged commit 8424f8e into rust-lang:master Jan 18, 2024
23 checks passed
@rustbot rustbot added this to the 1.77.0 milestone Jan 18, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#119172 Detect NulInCStr error earlier. ffce981ee31bdf43824afce98b0bcb57082606ff (link)
#119833 Make tcx optional from StableMIR run macro and extend it to… 6540b2f89414b54f681720e55719ec0a380a68fa (link)
#119967 Add PatKind::Err to AST/HIR c75587a7331b8895d884967e1d27a3384f4b1559 (link)
#119978 Move async closure parameters into the resultant closure's … b5f87da3aa2dd036ae2b0e826a33fedbf50fbe9e (link)
#120021 don't store const var origins for known vars d898f1f72306593ca0a1d2f787625aa6b793a8da (link)
#120038 Don't create a separate "basename" when naming and opening … 7d6810fbcc8c95f9212e87181dc20adc597c2a11 (link)
#120057 Don't ICE when deducing future output if other errors alrea… 53982cdba103d7fb58cbaf1750d0303bd0a4064f (link)
#120073 Remove spastorino from users_on_vacation be29f28e20c4d9bc9e58d7aacb651b20a9635a67 (link)

previous master: a34faab155

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 (8424f8e): 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

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)
2.0% [1.8%, 2.6%] 3
Improvements ✅
(primary)
-0.7% [-0.7%, -0.7%] 1
Improvements ✅
(secondary)
-3.3% [-4.4%, -2.3%] 2
All ❌✅ (primary) -0.7% [-0.7%, -0.7%] 1

Cycles

Results

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

Binary size

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

Bootstrap: 666.175s -> 665.206s (-0.15%)
Artifact size: 308.36 MiB -> 308.34 MiB (-0.00%)

@matthiaskrgr matthiaskrgr deleted the rollup-xyfqrb5 branch March 16, 2024 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues about the rust-lang/rust repository. merged-by-bors This PR was explicitly merged by bors. 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.