Check for duplicate attributes.
This adds some checks for duplicate attributes. In many cases, the duplicates were being ignored without error or warning. This adds several kinds of checks (see `AttributeDuplicates` enum).
The motivation here is to issue unused warnings with similar reasoning for any unused lint, and to error for cases where there are conflicts.
This also adds a check for empty attribute lists in a few attributes where this causes the attribute to be ignored.
Closes#55112.
Rollup of 4 pull requests
Successful merges:
- #91008 (Adds IEEE 754-2019 minimun and maximum functions for f32/f64)
- #91070 (Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`)
- #91097 (Add spaces in opaque `impl Trait` with more than one trait)
- #91098 (Don't suggest certain fixups (`.field`, `.await`, etc) when reporting errors while matching on arrays )
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't suggest certain fixups (`.field`, `.await`, etc) when reporting errors while matching on arrays
When we have a type mismatch with a `cause.code` that is an `ObligationCauseCode::Pattern`, skip suggesting fixes like adding `.await` or accessing a struct's `.field` if the pattern's `root_ty` differs from the `expected` ty. This occurs in situations like this:
```rust
struct S(());
fn main() {
let array = [S(())];
match array {
[()] => {}
_ => {}
}
}
```
I think what's happening here is a layer of `[_; N]` is peeled off of both types and we end up seeing the mismatch between just `S` and `()`, but when we suggest a fixup, that applies to the expression with type `root_ty`.
---
Questions:
1. Should this check live here, above all of the suggestions, or should I push this down into every suggestion when we match `ObligationCauseCode`?
2. Any other `ObligationCauseCode`s to check here?
3. Am I overlooking an easier way to get to this same conclusion without pattern matching on `ObligationCauseCode` and comparing `root_ty`?
Fixes#91058
Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`
`Module::getOrInsertGlobal` returns a `Constant*`, which is a super
class of `GlobalVariable`, but if the given type doesn't match an
existing declaration, it returns a bitcast of that global instead.
This causes UB when we pass that to `LLVMGetVisibility` which
unconditionally casts the opaque argument to a `GlobalValue*`.
Instead, we can do our own get-or-insert without worrying whether
existing types match exactly. It's not relevant when we're just trying
to get/set the linkage and visibility, and if types are needed we can
bitcast or error nicely from `rustc_codegen_llvm` instead.
Fixes#91050, fixes#87933, fixes#87813.
Point at source of trait bound obligations in more places
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
We no longer point at associated items (`ImplObligation`), as they didn't
add any user actionable information, they just added noise.
Address part of #89418.
Suggest `await` in more situations where infer types are involved
Currently we use `TyS::same_type` in diagnostics that suggest adding `.await` to opaque future types.
This change makes the suggestion slightly more general, when we're comparing types like `Result<T, E>` and `Result<_, _>` which happens sometimes in places like `match` patterns or `let` statements with partially-elaborated types.
----
Question:
1. Is this change worthwhile? Totally fine if it doesn't make sense adding.
2. Should `same_type_modulo_infer` live in `rustc_infer::infer::error_reporting` or alongside the other method in `rustc_middle::ty::util`?
3. Should we generalize this change? I wanted to change all usages, but I don't want erroneous suggestions when adding `.field_name`...
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
Address part of #89418.
Elaborate `Future::Output` when printing opaque `impl Future` type
I would love to see the `Output =` type when printing type errors involving opaque `impl Future`.
[Test code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a800b481edd31575fbcaf5771a9c3678)
Before (cut relevant part of output):
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future`
```
After:
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future<Output = usize>`
```
Note the "found opaque type `impl Future<Output = usize>`" in the new output.
----
Questions:
1. We skip printing the output type when it's a projection, since I have been seeing some types like `impl Future<Output = <[static generator@/home/michael/test.rs:2:11: 2:21] as Generator<ResumeTy>>::Return>` which are not particularly helpful and leak implementation detail.
* Am I able to normalize this type within `rustc_middle::ty::print::pretty`? Alternatively, can we normalize it when creating the diagnostic? Otherwise, I'm fine with skipping it and falling back to the old output.
* Should I suppress any other types? I didn't encounter anything other than this generator projection type.
2. Not sure what the formatting of this should be. Do I include spaces in `Output = `?
Fix `non-constant value` ICE (#90878)
This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const.
I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong.
Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.
Asking Esteban to review since he was the last one to change the relevant code.
r? ``@estebank``
Fixes#90878
Clarify error messages caused by re-exporting `pub(crate)` visibility to outside
This PR clarifies error messages and suggestions caused by re-exporting pub(crate) visibility outside the crate.
Here is a small example ([Rust Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e2cd0bd4422d4f20e6522dcbad167d3b)):
```rust
mod m {
pub(crate) enum E {}
}
pub use m::E;
fn main() {}
```
This code is compiled to:
```
error[E0365]: `E` is private, and cannot be re-exported
--> prog.rs:4:9
|
4 | pub use m::E;
| ^^^^ re-export of private `E`
|
= note: consider declaring type or module `E` with `pub`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0365`.
```
However, enum `E` is actually public to the crate, not private totally—nevertheless, rustc treats `pub(crate)` and private visibility as the same on the error messages. They are not clear and should be segmented distinctly.
By applying changes in this PR, the error message below will be the following message that would be clearer:
```
error[E0365]: `E` is only public to inside of the crate, and cannot be re-exported outside
--> prog.rs:4:9
|
4 | pub use m::E;
| ^^^^ re-export of crate public `E`
|
= note: consider declaring type or module `E` with `pub`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0365`.
```
`Module::getOrInsertGlobal` returns a `Constant*`, which is a super
class of `GlobalVariable`, but if the given type doesn't match an
existing declaration, it returns a bitcast of that global instead.
This causes UB when we pass that to `LLVMGetVisibility` which
unconditionally casts the opaque argument to a `GlobalValue*`.
Instead, we can do our own get-or-insert without worrying whether
existing types match exactly. It's not relevant when we're just trying
to get/set the linkage and visibility, and if types are needed we can
bitcast or error nicely from `rustc_codegen_llvm` instead.
rustdoc doctest: detect `fn main` after an unexpected semicolon
Fixes#91014
The basic problem with this is that rustdoc, when hunting for `fn main`, will stop parsing after it reaches a fatal error. This unexpected semicolon was a fatal error, so in `src/test/rustdoc-ui/failed-doctest-extra-semicolon-on-item.rs`, it would wrap the doctest in an implied main function, turning it into this:
fn main() {
struct S {};
fn main() {
assert_eq!(0, 1);
}
}
This, as it turns out, is totally valid, and it executes no assertions, so *it passes,* even though the user wanted it to execute the assertion.
The Rust parser already has the ability to recover from these unexpected semicolons, but to do so, it needs to use the `parse_mod` function, so this PR changes it to do that.
fix CTFE/Miri simd_insert/extract on array-style repr(simd) types
The changed test would previously fail since `place_index` would just return the only field of `f32x4`, i.e., the array -- rather than *indexing into* the array which is what we have to do.
The new helper methods will also be needed for https://github.com/rust-lang/miri/issues/1912.
r? ``````@oli-obk``````
Rollup of 8 pull requests
Successful merges:
- #89258 (Make char conversion functions unstably const)
- #90578 (add const generics test)
- #90633 (Refactor single variant `Candidate` enum into a struct)
- #90800 (bootstap: create .cargo/config only if not present)
- #90942 (windows: Return the "Not Found" error when a path is empty)
- #90947 (Move some tests to more reasonable directories - 9.5)
- #90961 (Suggest removal of arguments for unit variant, not replacement)
- #90990 (Arenas cleanup)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Try all stable method candidates first before trying unstable ones
Currently we try methods in this order in each step:
* Stable by value
* Unstable by value
* Stable autoref
* Unstable autoref
* ...
This PR changes it to first try pick methods without any unstable candidates, and if none is found, try again to pick unstable ones.
Fix#90320
CC #88971, hopefully would allow us to rename the "unstable_*" methods for integer impls back.
`@rustbot` label T-compiler T-libs-api
The basic problem with this is that rustdoc, when hunting for `fn main`, will stop
parsing after it reaches a fatal error. This unexpected semicolon was a fatal error,
so in `src/test/rustdoc-ui/failed-doctest-extra-semicolon-on-item.rs`, it would wrap
the doctest in an implied main function, turning it into this:
fn main() {
struct S {};
fn main() {
assert_eq!(0, 1);
}
}
This, as it turns out, is totally valid, and it executes no assertions, so *it passes,*
even though the user wanted it to execute the assertion.
The Rust parser already has the ability to recover from these unexpected semicolons,
but to do so, it needs to use the `parse_mod` function, so this commit changes it to do that.
