Given a code
```rust
fn foo(x: u8, y: u32) -> bool {
x > y
}
fn main() {}
```
it could be more helpful to provide a suggestion to do "u32::from(x)"
rather than "y.try_into().unwrap()", since the latter may panic.
We do this by passing the LHS of a binary expression up the stack into
the coercion checker.
Closes#73145
Support proc macros in intra doc link resolution
The feature was written pre-proc macro resolution, so it only supported the wacky MBE resolution rules. This adds support for proc macros as well.
cc @GuillaumeGomez
Fixes#73173
Ensure stack when building MIR for matches
In particular matching on complex types such as strings will cause
deep recursion to happen.
Fixes#72933
r? @matthewjasper @oli-obk
Fix `is_const_context`, update `check_for_cast`
A better version of #71477
Adds `fn enclosing_body_owner` and uses it in `is_const_context`.
`is_const_context` now uses the same mechanism as `mir_const_qualif` as it was previously incorrect.
Renames `is_const_context` to `is_inside_const_context`.
I also updated `check_for_cast` in the second commit, so r? @estebank
(I removed one lvl of indentation, so it might be easier to review by hiding whitespace changes)
Relate existential associated types with variance Invariant
Fixes#71550#72315
r? @nikomatsakis
The test case reported in that issue now errors with the following message ...
```
error[E0495]: cannot infer an appropriate lifetime for lifetime parameter 'a in function call due to conflicting requirements
--> /tmp/test.rs:25:5
|
25 | bad(&Bar(PhantomData), x)
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: first, the lifetime cannot outlive the lifetime `'a` as defined on the function body at 24:11...
--> /tmp/test.rs:24:11
|
24 | fn extend<'a, T>(x: &'a T) -> &'static T {
| ^^
note: ...so that reference does not outlive borrowed content
--> /tmp/test.rs:25:28
|
25 | bad(&Bar(PhantomData), x)
| ^
= note: but, the lifetime must be valid for the static lifetime...
note: ...so that the types are compatible
--> /tmp/test.rs:25:9
|
25 | bad(&Bar(PhantomData), x)
| ^^^^^^^^^^^^^^^^^
= note: expected `&'static T`
found `&T`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0495`.
```
I could also add that test case if we want to have a weaponized one too.
Rollup of 9 pull requests
Successful merges:
- #72706 (Add windows group to triagebot)
- #72789 (resolve: Do not suggest imports from the same module in which we are resolving)
- #72890 (improper ctypes: normalize return types and transparent structs)
- #72897 (normalize adt fields during structural match checking)
- #73005 (Don't create impl candidates when obligation contains errors)
- #73023 (Remove noisy suggestion of hash_map )
- #73070 (Add regression test for const generic ICE in #72819)
- #73157 (Don't lose empty `where` clause when pretty-printing)
- #73184 (Reoder order in which MinGW libs are linked to fix recent breakage)
Failed merges:
r? @ghost
Fixes#69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
Fix emcc failure for wasm32.
The wasm32 job is currently failing on CI with the error `ERROR: llc executable not found at /usr/bin/llc`. The issue is that https://github.com/emscripten-core/emsdk/pull/472 has changed how emsdk discovers its configuration. We were relying on the global behavior that would use a configuration from the home directory. However, it looks like emsdk is moving away from that approach. This change adds the necessary env var for emcc to find the correct configuration.
There are a few alternate approaches this could take. The `--no-embedded` option could be passed to `emsdk activate` to use the old behavior, but it seems like they want to move away from that. Another option is to source `emsdk_env.sh`, which is how these env vars normally get set. I'm not entirely sure how to do that easily in a Dockerfile, though.
