when there are 3 or more return statements in the loop
emit the first 3 errors and duplicated diagnostic information
modified: compiler/rustc_typeck/src/check/coercion.rs
new file: src/test/ui/typeck/issue-100285.rs
new file: src/test/ui/typeck/issue-100285.stderr
emit the first 3 errors and duplicated diagnostic information
using take of iterator for the first third return
modified: compiler/rustc_typeck/src/check/coercion.rs
new file: src/test/ui/typeck/issue-100285.rs
new file: src/test/ui/typeck/issue-100285.stderr
Rollup of 6 pull requests
Successful merges:
- #100211 (Refuse to codegen an upstream static.)
- #100277 (Simplify format_args builtin macro implementation.)
- #100483 (Point to generic or arg if it's the self type of unsatisfied projection predicate)
- #100506 (change `InlineAsmCtxt` to not talk about `FnCtxt`)
- #100534 (Make code slightly more uniform)
- #100566 (Use `create_snapshot_for_diagnostic` instead of `clone` for `Parser`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
change `InlineAsmCtxt` to not talk about `FnCtxt`
wip for https://github.com/rust-lang/compiler-team/issues/529. this currently uses both the `FnCtxt` and is used by `check_mod_item_types`. This should be the only thing blocking that MCP afaict.
I am still unsure whether `rustc_hir_typeck` should depend on `rustc_hir_analysis` to use the `InlineAsmCtxt`. I think that's the best solution for now, so that's what I will go for
r? `@compiler-errors`
Point to generic or arg if it's the self type of unsatisfied projection predicate
We do this for `TraitPredicate`s in `point_at_type_arg_instead_of_call_if_possible` and `point_at_arg_instead_of_call_if_possible`, so also do it for `ProjectionPredicate`.
Improves spans for a lot of unit tests.
Visit attributes in more places.
This adds 3 loosely related changes (I can split PRs if desired):
- Attribute checking on pattern struct fields.
- Attribute checking on struct expression fields.
- Lint level visiting on pattern struct fields, struct expression fields, and generic parameters.
There are still some lints which ignore lint levels in various positions. This is a consequence of how the lints themselves are implemented. For example, lint levels on associated consts don't work with `unused_braces`.
Argument type error improvements
Motivated by this interesting code snippet:
```rust
#[derive(Copy, Clone)]
struct Wrapper<T>(T);
fn foo(_: fn(i32), _: Wrapper<i32>) {}
fn f(_: u32) {}
fn main() {
let w = Wrapper::<isize>(1isize);
foo(f, w);
}
```
Which currently errors like:
```
error[E0308]: arguments to this function are incorrect
--> src/main.rs:10:5
|
10 | foo(f, w);
| ^^^ - - expected `i32`, found `isize`
| |
| expected `i32`, found `u32`
|
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> src/main.rs:4:4
|
4 | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
```
Specifically, that double `expected .. found ..` which is very difficult to correlate to the types in the arguments. Also, the fact that "expected `i32`, found `isize`" and the other argument mismatch label don't even really explain what's going on here.
After this PR:
```
error[E0308]: arguments to this function are incorrect
--> $DIR/two-mismatch-notes.rs:10:5
|
LL | foo(f, w);
| ^^^
|
note: expected fn pointer, found fn item
--> $DIR/two-mismatch-notes.rs:10:9
|
LL | foo(f, w);
| ^
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
note: expected struct `Wrapper`, found a different struct `Wrapper`
--> $DIR/two-mismatch-notes.rs:10:12
|
LL | foo(f, w);
| ^
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> $DIR/two-mismatch-notes.rs:4:4
|
LL | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
```
Yeah, it's a bit verbose, but much clearer IMO.
---
Open to discussions about how this could be further improved. Motivated by `@jyn514's` [tweet](https://mobile.twitter.com/joshuayn514/status/1558042020601634816) here.
Generalize trait object generic param check to aliases.
The current algorithm only checks that `Self` does not appear in defaults for traits. This is not sufficient for trait aliases.
This PR moves the check to trait object elaboration, which sees through trait aliases.
Fixes https://github.com/rust-lang/rust/issues/82927.
Fixes https://github.com/rust-lang/rust/issues/84789.
This was incorrectly inserting the ExprField as a sibling of the struct
expression.
This required adjusting various parts which were looking at parent node
of a field expression to find the struct.
Attributes on struct expression fields were not being checked for
validity. This adds the fields as HIR nodes so that `CheckAttrVisitor`
can visit those nodes to check their attributes.
Attributes on pattern struct fields were not being checked for validity.
This adds the fields as HIR nodes so that the `CheckAttrVisitor` can
visit those nodes to check their attributes.
Use `&mut Diagnostic` instead of `&mut DiagnosticBuilder` unless needed
This seems to be the established convention (02ff9e0) when `DiagnosticBuilder` was first added. I am guilty of introducing some of these.
Check if enum from foreign crate has any non exhaustive variants when attempting a cast
Fixes#91161
As stated in the issue, this will require a crater run as it might break other people's stuff.
Set tainted errors bit before emitting coerce suggestions.
Fixes#100246.
#89576 basically got 99% of the way there but the match typechecking code (which calls `coerce_inner`) also needed a similar fix.
Add some high-level docs to `FnCtxt` and `ItemCtxt`
I haven't understood the difference between these before, but
``@compiler-errors`` helped me clear it up. Hopefully this will help other
people who've been confused!
r? `@compiler-errors`
Some "this expression has a field"-related fixes
Each commit does something different and is worth reviewing, but the final diff from `master..HEAD` contains the sum of the changes to the UI tests, since some commits added UI tests "regressions" which were later removed in other commits.
The only change I could see adding on top of this is suppressing `Clone::clone` from the "this expression has a field that has this method" suggestion, since it's so commonly implemented by types that it's not worthwhile suggesting in general.
consider unnormalized types for implied bounds
extracted, and slightly modified, from #98900
The idea here is that generally, rustc is split into things which can assume its inputs are well formed[^1], and things which have verify that themselves.
Generally most predicates should only deal with well formed inputs, e.g. a `&'a &'b (): Trait` predicate should be able to assume that `'b: 'a` holds. Normalization can loosen wf requirements (see #91068) and must therefore not be used in places which still have to check well formedness. The only such place should hopefully be `WellFormed` predicates
fixes#87748 and #98543
r? `@jackh726` cc `@rust-lang/types`
[^1]: These places may still encounter non-wf inputs and have to deal with them without causing an ICE as we may check for well formedness out of order.
Implement `#[rustc_default_body_unstable]`
This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.
`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
#[rustc_default_body_unstable(feature = "feat", isssue = "none")]
fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`
This is useful in conjunction with [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/pull/92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.
r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
