Rollup of 9 pull requests #118881
Merged
Rollup of 9 pull requests #118881
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There has been some confusion about how to choose these variants, or what the procedure is for handling future-incompatible errors. Hopefully this helps provide some more information on how these work.
When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix rust-lang#85843.
When encountering
```rust
fn g(mut x: impl Iterator<Item = &()>) -> Option<&()> { /* */ }
```
Suggest
```rust
fn g<'a>(mut x: impl Iterator<Item = &'a ()>) -> Option<&'a ()> { /* */ }
```
Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.: ``` unexpected expression: 1 + 1 ``` You also get the same error if the attribute value is a literal, but an invalid literal, e.g.: ``` unexpected expression: "foo"suffix ``` This commit does two things. - Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway. - Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level.
The `c === "="` was redundant when `isSeparatorCharacter` already checks that. The function `isStopCharacter` and `isEndCharacter` functions did exactly the same thing and have synonymous names. There doesn't seem much point in having both.
Stop allowing `rustc::potential_query_instability` on all of `rustc_codegen_llvm` and instead allow it on a case-by-case basis. In this case, both instances are safe to allow.
LLVM commit llvm/llvm-project@f09cf34 moved some functions to a different header: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24416#018c5de6-b9c9-4b22-9473-6070d99dcfa7/233-537
CGU tests require CGU code to be exercised. We can't merely do "cargo check" on these tests.
…or_non_unevaluated_const, r=BoxyUwU dont ICE when ConstKind::Expr for is_const_evaluatable The problem is that we are not handling ConstKind::Expr inside report_not_const_evaluatable_error Fixes [rust-lang#114151]
On borrow return type, suggest borrowing from arg or owned return type
When we encounter a function with a return type that has an anonymous lifetime with no argument to borrow from, besides suggesting the `'static` lifetime we now also suggest changing the arguments to be borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix rust-lang#85843.
…eywiser Clarify how to choose a FutureIncompatibilityReason variant. There has been some confusion about how to choose these variants, or what the procedure is for handling future-incompatible errors. Hopefully this helps provide some more information on how these work.
…e-error, r=compiler-errors,petrochenkov Improve an error involving attribute values. Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.: ``` unexpected expression: 1 + 1 ``` You also get the same error if the attribute value is a literal, but an invalid literal, e.g.: ``` unexpected expression: "foo"suffix ``` This commit does two things. - Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway. - Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level. r? `@compiler-errors`
…uillaumeGomez rustdoc-search: clean up parser The `c === "="` was redundant when `isSeparatorCharacter` already checks that. The function `isStopCharacter` and `isEndCharacter` functions did exactly the same thing and have synonymous names. There doesn't seem much point in having both.
…x, r=petrochenkov rustc_codegen_llvm: Enforce `rustc::potential_query_instability` lint Stop allowing `rustc::potential_query_instability` on all of `rustc_codegen_llvm` and instead allow it on a case-by-case basis if it is safe to do so. In this case, all 2 instances are safe to allow. Part of rust-lang#84447 which is E-help-wanted.
llvm-wrapper: adapt for LLVM API change LLVM commit llvm/llvm-project@f09cf34 (old) moved some functions to a different header. It looks we were getting it transitively in PassWrapper, and something in LLVM recently removed it from the set of transitively available headers, so include it directly: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24416#018c5de6-b9c9-4b22-9473-6070d99dcfa7/233-537 r? `@nikic`
…terns-parsing, r=petrochenkov Correctly gate the parsing of match arms without body rust-lang#118527 accidentally allowed the following to parse on stable: ```rust match Some(0) { None => { foo(); } #[cfg(FALSE)] Some(_) } ``` This fixes that oversight. The way I choose which error to emit is the best I could think of, I'm open if you know a better way. r? `@petrochenkov` since you're the one who noticed
tests: CGU tests require build-pass, not check-pass (remove FIXME) CGU tests require CGU code to be exercised. We can't merely do "cargo check" on these tests. Part of rust-lang#62277
rustbot
added
A-testsuite
rustbot
added
T-compiler
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 835ed0021e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Dec 12, 2023
|
Finished benchmarking commit (028b6d1): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.534s -> 673.638s (0.16%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
rustc::potential_query_instabilitylint #118865 (rustc_codegen_llvm: Enforcerustc::potential_query_instabilitylint)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup