-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #73246
Rollup of 7 pull requests #73246
Conversation
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.
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.
Fixes rust-lang#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 rust-lang#72389 (comment)
…Dylan-DPC 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 ```
…r=matthewjasper 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.
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.
Handle assembler warnings properly Previously all inline asm diagnostics were treated as errors, but LLVM sometimes emits warnings and notes as well. Fixes rust-lang#73160 r? @petrochenkov
…atthewjasper Track span of function in method calls, and use this in #[track_caller] Fixes rust-lang#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 rust-lang#72389 (comment)
…an-DPC Clean up E0648 explanation r? @Dylan-DPC
Suggest including unused asm arguments in a comment to avoid error We require all arguments to an `asm!` to be used in the template string, just like format strings. However in some cases (e.g. `black_box`) it may be desirable to have `asm!` arguments that are not used in the template string. Currently this is a hard error rather than a lint since `#[allow]` does not work on macros (rust-lang#63221), so this PR suggests using the unused arguments in an asm comment as a workaround. r? @petrochenkov
@bors r+ rollup=never p=7 |
📌 Commit 8650df5 has been approved by |
☀️ Test successful - checks-azure |
📣 Toolstate changed by #73246! Tested on commit a37c32e. 🎉 rls on windows: build-fail → test-pass (cc @Xanewok). |
Tested on commit rust-lang/rust@a37c32e. Direct link to PR: <rust-lang/rust#73246> 🎉 rls on windows: build-fail → test-pass (cc @Xanewok). 🎉 rls on linux: build-fail → test-pass (cc @Xanewok). 🎉 rustfmt on windows: build-fail → test-pass (cc @topecongiro). 🎉 rustfmt on linux: build-fail → test-pass (cc @topecongiro).
Something in this rollup broke Miri, it now ICEs with
But for some reason its toolstate is still green. @Xanewok @Mark-Simulacrum is it expected that this fixed rls/rustfmt toolstate without changing those tools? Given that this landed a change in the toolstate logic in bootstrap, maybe that logic is just wrong now and reports all tools as working? |
Yes, it 'fixed' the toolstate but it's still broken as far as I can tell. |
Very strange. I'll take a look, the change should have only affected clippy... |
Successful merges:
SyntaxContext
in formattedSpan
debug output #73012 (ShowSyntaxContext
in formattedSpan
debug output)Failed merges:
r? @ghost