Rollup of 8 pull requests by matthiaskrgr · Pull Request #120089 · rust-lang/rust

matthiaskrgr · 2024-01-18T09:34:21Z

Successful merges:

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

r? @ghost
@rustbot modify labels: rollup

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``` fixesrust-lang#119890

…cations, r=fmease Remove spastorino from users_on_vacation

matthiaskrgr · 2024-01-18T09:34:50Z

@bors r+ rollup=never p=8

bors · 2024-01-18T09:34:53Z

📌 Commit 054a435 has been approved by matthiaskrgr

It is now in the queue for this repository.

bors · 2024-01-18T10:07:16Z

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

…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 · 2024-01-18T14:15:42Z

@bors r-

matthiaskrgr · 2024-01-18T14:15:55Z

@bors r+

bors · 2024-01-18T14:15:57Z

📌 Commit 054a435 has been approved by matthiaskrgr

It is now in the queue for this repository.

rust-log-analyzer · 2024-01-18T14:17:34Z

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

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

bors · 2024-01-18T16:39:37Z

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

bors · 2024-01-18T18:53:08Z

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

rust-timer · 2024-01-18T18:55:24Z

📌 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 · 2024-01-18T20:17:12Z

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%)

nnethercoteand others added 22 commits January 12, 2024 16:19

don't store const var origins for known vars
290651b

Introduce helper that deals with moving async args into the coroutine
8bb1eae

Async closures will move params into the future always
f1ee076

Fix async closure call suggestion
f4e35c6

Deal with additional wrapping of async closure body in clippy
04a5ee6

Remove tcx function and make internal fn safer
2564811
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`.

Inline create_dump_file_with_basename
b82d1d3

Inline dump_file_basename into dump_path
1ec567b

Add PatKind::Err
7889e99

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

Remove spastorino from users_on_vacation
eb8c1f8

Revert changes to internal method for now
6a573cb
- Move fix to a separate PR

Rollup merge ofrust-lang#119967- ShE3py:patkind-err, r=WaffleLapkin
1f93d2b
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

Rollup merge ofrust-lang#120021- lcnr:const-var-value, r=compiler-e…
b185606
…rrors don't store const var origins for known vars r? types

Rollup merge ofrust-lang#120073- spastorino:remove-spastorino-on-va…
054a435
…cations, r=fmease Remove spastorino from users_on_vacation

bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 18, 2024

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 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 closed this Jan 18, 2024

matthiaskrgr reopened this Jan 18, 2024

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

bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 18, 2024

bors merged commit 8424f8e into rust-lang:masterJan 18, 2024

rustbot added this to the 1.77.0 milestone Jan 18, 2024

This was referenced Jan 18, 2024
Improve handling of expressions in patterns #118625
Merged
remove sub_relations from the InferCtxt#119989
Merged
never_patterns: typecheck never patterns #120009
Merged

matthiaskrgr deleted the rollup-xyfqrb5 branch March 16, 2024 18:20

Navigation Menu

Uh oh!

Uh oh!

Rollup of 8 pull requests - #120089

Rollup of 8 pull requests#120089
bors merged 22 commits into
rust-lang:masterfrom
matthiaskrgr:rollup-xyfqrb5

matthiaskrgr commented Jan 18, 2024

Uh oh!

matthiaskrgr commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

matthiaskrgr commented Jan 18, 2024

Uh oh!

matthiaskrgr commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

rust-log-analyzer commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

rust-timer commented Jan 18, 2024

Uh oh!

rust-timer commented Jan 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

13 participants

Uh oh!

Uh oh!

Conversation

matthiaskrgr commented Jan 18, 2024

Uh oh!

matthiaskrgr commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

matthiaskrgr commented Jan 18, 2024

Uh oh!

matthiaskrgr commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

rust-log-analyzer commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

bors commented Jan 18, 2024

Uh oh!

rust-timer commented Jan 18, 2024

Uh oh!

rust-timer commented Jan 18, 2024

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

13 participants