Rollup of 6 pull requests #152032
Closed
Rollup of 6 pull requests #152032
+7,695
−2,221
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix not applicable in statement when exist else block
Example
---
```rust
fn main() {
some_statements();
if$0 let Ok(x) = Err(92) {
foo(x);
} else {
return;
}
some_statements();
}
```
**Before this PR**
Assist not applicable
**After this PR**
```rust
fn main() {
some_statements();
let Ok(x) = Err(92) else {
return;
};
foo(x);
some_statements();
}
```
Add proper line/column resolution for proc-macro spans via a callback mechanism. Previously these methods returned hardcoded 1 values. The implementation adds: - SubRequest::LineColumn and SubResponse::LineColumnResult to the bidirectional protocol - ProcMacroClientInterface::line_column() method - Callback handling in load-cargo using LineIndex - Server implementation in RaSpanServer that uses the callback - a test for Span::line() and Span::column() in proc-macro server Add fn_like_span_line_column test proc-macro that exercises the new line/column API, and a corresponding test with a mock callback.
Implement Span::line() and Span::column() for proc-macro server
perf: Re-use scratch allocations for `try_evaluate_obligations`
Example
---
```rust
fn main() {
let cond = true;
match 92 {
3 => true,
x if cond => if x $0> 10 {
false
} else if x > 5 {
true
} else if x > 4 || x < -2 {
false
} else {
true
},
}
}
```
**Before this PR**
```rust
fn main() {
let cond = true;
match 92 {
3 => true,
x if x > 10 => false,
x if x > 5 => true,
x if x > 4 || x < -2 => false,
x => true,
}
}
```
**After this PR**
```rust
fn main() {
let cond = true;
match 92 {
3 => true,
x if cond && x > 10 => false,
x if cond && x > 5 => true,
x if cond && (x > 4 || x < -2) => false,
x if cond => true,
}
}
```
fix: Suggest traits other than ones in the environment crate
Needed to support flychecking in a later diff
Needed for all_workspace_dependencies_for_package implementation.
This exited the whole loop instead of having continue semantics and continuing to find workspaces. So wrap in find_map.
You should be able to flycheck a ProjectJson crate based on its build label. This paves the way for that. Context: I don't think this has been working for some time. It used to be that we would use cargo to build ProjectJson crates. Support for ProjectJson seems to have been somewhat steamrolled in PR 18845 (e4bf6e1bc36e4cbc8a36d7911788176eb9fac76e).
We need to distinguish from RunnableKind::Check, which is human-readable.
This adds a substitution helper to get the right behaviour re {label} and $saved_file.
… rust-project.json
This requires us to add $saved_file / {saved_file} interpolation back to restart_for_package.
Otherwise we break existing users of $saved_file. No grand reason why we can't delete saved_file
later, although I would just leave it because sometimes a build system might really know better
which target(s) to build, including multiple targets.
…run in a notification
…roject.json runnable For JSON / override users, pretty-print the custom flycheck command with fewer quote characters Better debug logging in flycheck
Because (1) it is what we use when there is no relevant config
(2) we automatically use either rust-project.json's flycheck, or cargo
This also puts check_command config into CargoOptions. It's a cargo option, after all.
It was pretty useless without this.
Previously:
Parsing target pattern `{label}`
Caused by:
Invalid target name `{label}`. (...)
Build ID: 6dab5942-d81c-4430-83b0-5ba523999050
Network: Up: 0B Down: 0B
Command: run.
Time elapsed: 0.3s
BUILD FAILED
* The terminal process "buck2 'run', '{label}'" terminated with exit code: 3.
rust-project requires {arg} these days. No good giving people bad information
even if it's not crucial to documenting this.
I am not familiar with this code at allso just doing what I can to unblock.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@7cb789d. Created using https://github.com/rust-lang/josh-sync. r? @ghost
fN::BITS constants for feature float_bits_const Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait. --- Implementation for rust-lang#151073 Feature flag: `#![feature(float_bits_const)]` Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value. Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
…ethercote Rename `collect_active_jobs` to several distinct names Key renames: - Function `collect_active_jobs` → `collect_active_jobs_from_all_queries` (method in trait `QueryContext`) - Constant `COLLECT_ACTIVE_JOBS` → `PER_QUERY_GATHER_ACTIVE_JOBS_FNS` (list of per-query function pointers) - Function `collect_active_jobs` → `gather_active_jobs` (per-query function in `query_impl::$name`) - Function `collect_active_jobs` → `gather_active_jobs_inner` (method in `QueryState`) - Giving these four things distinct names makes it a lot easier to tell them apart! - The switch from “collect” (all queries) to “gather” (single query) is intended to make the different parts a bit more memorable and searchable; I couldn't think of a more natural way to express this distinction so I settled for two different synonyms. There should be no change to compiler behaviour. r? nnethercote (or compiler)
…mic-v2, r=jdonszelmann
compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`
Since it does not make sense to do so. If someone prefers no dynamic stuff, the last thing they want to look for is an .so file. Also add a regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
### Needed by:
- rust-lang#150591 because of rust-lang#151271. But IMHO this PR makes sense on its own.
### Must wait for:
- [x] rust-lang#151695
…hercote fix: Make `--color always` always print color with `--explain` Fixes rust-lang#151643. This changes the behaviour of `handle_explain` in `rustc_driver_impl` to always output color when the `--color always` flag is set. r? @tgross35
…r=jdonszelmann Convert to inline diagnostics in `rustc_driver_impl` Converts a crate for rust-lang#151366 This PR is almost completely autogenerated by a hacky script I have locally :)
rustbot
added
A-compiler-builtins
Member
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 3, 2026
Rollup of 6 pull requests Successful merges: - #152008 (`rust-analyzer` subtree update) - #151109 (fN::BITS constants for feature float_bits_const) - #151976 (Rename `collect_active_jobs` to several distinct names) - #151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`) - #151919 (fix: Make `--color always` always print color with `--explain`) - #152028 (Convert to inline diagnostics in `rustc_driver_impl`)
rust-bors
bot
added
S-waiting-on-review
Contributor
Member
|
@Kobzol I think something weird happened to bors here that might warrant a look. Something about a “higher priority” job that never actually existed. |
Member
|
Interesting, seems like GitHub started the CI workflow twice for the same commit. I'll examine the logs. Even though bors is prepared for multiple workflows, there are some diagnostics that don't handle it well, as the previous bors comment shows. I'll fix that too. |
Member
|
Yeah so we definitely received a webhook that the |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
rust-analyzersubtree update #152008 (rust-analyzersubtree update)collect_active_jobsto several distinct names #151976 (Renamecollect_active_jobsto several distinct names)aux-cratebecomes a*.sowithno-prefer-dynamic#151691 (compiletest: Don't assumeaux-cratebecomes a*.sowithno-prefer-dynamic)--color alwaysalways print color with--explain#151919 (fix: Make--color alwaysalways print color with--explain)rustc_driver_impl#152028 (Convert to inline diagnostics inrustc_driver_impl)r? @ghost
Create a similar rollup