Track span of function in method calls, and use this in #[track_caller]
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
Handle assembler warnings properly
Previously all inline asm diagnostics were treated as errors, but LLVM sometimes emits warnings and notes as well.
Fixes#73160
r? @petrochenkov
Try_run must only be used if toolstate is populated
Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build.
The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI, but that's not the case specifically for tool testing.
Show `SyntaxContext` in formatted `Span` debug output
This is only really useful in debug messages, so I've switched to
calling `span_to_string` in any place that causes a `Span` to end up in
user-visible output.
remove extra space from crate-level doctest names
Before:
```
running 2 tests
test src/test/rustdoc-ui/doctest-output.rs - foo::bar (line 11) ... ok
test src/test/rustdoc-ui/doctest-output.rs - (line 5) ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
After:
```
running 2 tests
test src/test/rustdoc-ui/doctest-output.rs - foo::bar (line 11) ... ok
test src/test/rustdoc-ui/doctest-output.rs - (line 5) ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
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.
Reoder order in which MinGW libs are linked to fix recent breakage
Recent upstream mingw-w64 changes made libmsvcrt depend on libmingwex breaking compilation in some cases when using **external** MinGW.
Applying this change to the master fixes nightly and stage{1,2} build. For stage0 one has to export `RUSTFLAGS_BOOTSTRAP='-C link-arg=-lmsvcrt'` until this PR lands in bootstrap compiler.
Therefore I'm humbly asking to also backport it to the beta and update bootstrap compiler.
Don't lose empty `where` clause when pretty-printing
Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.
We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing
Don't create impl candidates when obligation contains errors
Fixes#72839
In PR #72621, trait selection was modified to no longer bail out early
when an error type was encountered. This allowed us treat `ty::Error` as
`Sized`, causing us to avoid emitting a spurious "not sized" error after
a type error had already occured.
However, this means that we may now try to match an impl candidate
against the error type. Since the error type will unify with almost
anything, this can cause us to infinitely recurse (eventually triggering
an overflow) when trying to verify certain `where` clauses.
This commit causes us to skip generating any impl candidates when an
error type is involved.
normalize adt fields during structural match checking
fixes#72896
currently only fixes the issue itself and compiles stage 1 libs.
I believe we have to use something else to normalize the adt fields here,
as I expect some partially resolved adts to cause problems 🤔
stage 1 libs and the test itself pass, not sure about the rest...
Will spend some more time looking into it tomorrow.
r? @pnkfelix cc @eddyb
improper ctypes: normalize return types and transparent structs
Fixes#66202.
See each commit individually (except the first which adds a test) for more detailed explanations on the changes made.
In summary, this PR ensures that return types are normalized before being checked for FFI-safety, and that transparent newtype wrappers are FFI-safe if the type being wrapped is FFI-safe (often true previously, but not if, after substitution, all types in a transparent newtype were zero sized).
Dylan DPC
bors
Amanieu d'Antras
Aaron Hill
Ralf Jung
Manish Goregaokar
Eric Huss
Mihail Malo
Guillaume Gomez
Santiago Pastorino