-
Couldn't load subscription status.
- Fork 13.9k
rust-analyzer subtree update
#146749
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
rust-analyzer subtree update
#146749
Conversation
Bumps [tmp](https://github.com/raszi/node-tmp) from 0.2.3 to 0.2.4. - [Changelog](https://github.com/raszi/node-tmp/blob/master/CHANGELOG.md) - [Commits](raszi/node-tmp@v0.2.3...v0.2.4) --- updated-dependencies: - dependency-name: tmp dependency-version: 0.2.4 dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
…ast_instead_of_str In handlers/extract_module.rs, generate ast::Module instead of String
…yarn/editors/code/tmp-0.2.4 Bump tmp from 0.2.3 to 0.2.4 in /editors/code
…qymsto Disable error log for position clamping, its too noisy due to ease of triggering
remove duplicate field in Debug impl of ProjectWorkspace
…on_generate_by_indent_token fix: generate function by indet token
Add write! and writeln! to minicore
The rustc AST allows both `for<>` binders and `?` polarity
modifiers in trait bounds, but they are parsed in a specific
order and validated for correctness:
1. `for<>` binder is parsed first.
2. Polarity modifiers (`?`, `!`) are parsed second.
3. The parser validates that binders and polarity modifiers
do not conflict:
```rust
if let Some(binder_span) = binder_span {
match modifiers.polarity {
BoundPolarity::Maybe(polarity_span) => {
// Error: "for<...> binder not allowed with ? polarity"
}
}
}
```
This implies:
- `for<> ?Sized` → Valid syntax. Invalid semantics.
- `?for<> Sized` → Invalid syntax.
However, rust-analyzer incorrectly had special-case logic that
allowed `?for<>` as valid syntax. This fix removes that incorrect
special case, making rust-analyzer reject `?for<> Sized` as a
syntax error, matching rustc behavior.
This has caused confusion in other crates (such as syn) which
rely on these files to implement correct syntax evaluation.
**Input**:
```rust
fn main() {
write!(f, "{2+3}$0")
}
```
**Old output**:
```rust
fn main() {
write!("{}"$0, 2+3)
}
```
**This PR output**:
```rust
fn main() {
write!(f, "{}"$0, 2+3)
}
```
parser: fix parsing of trait bound polarity and for-binders
…m-fmtstr-on-write Fix extract_expressions_from_format_string on write!
internal: Make flycheck generational
This updates the rust-version file to 21a19c2.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 21a19c2 Filtered ref: 9a5c1fb93028e1a29a7598ce782efb0c5d7be534 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
hotfix: Update flycheck diagnostics generation
feat: Add Config Option to Exclude Locals from Document Symbol Search
minor: Bump rustc crates again
…tree fix: Fix `indexmap` with `in-rust-tree`
minor: Yet another rustc crates bump
fix: Fix one more thing in `in-rust-tree`
minor: Set `WithCachedTypeInfo::stable_hash` when in-tree
|
rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead. cc @rust-lang/rust-analyzer |
|
|
@bors r+ p=1 subtree sync |
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@50bb3c5. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
|
Seems to have failed in rollup? #146760 (comment) @bors r- |
|
Probably a conflict with #146638. |
|
Oh, so it is not failing against the current rustc HEAD but within rollup 🫠 So, are we gonna wait for the rollup to be merged, publish |
|
Yeah, that's likely. Not sure how common it is to preempt a subtree sync in favor of another PR, but I don't want to delay the next trait solver work :-). |
|
Yeah, I'm really looking forward to seeing this land soon as well. |
|
BTW #146638 is good for rust-analyzer as well. I'm gonna check whether we could use next-solver's canonicalizer in place of our current canonicalizer in rust-analyzer code that hand-ported from |
Subtree update of
rust-analyzerto rust-lang/rust-analyzer@50bb3c5.Created using https://github.com/rust-lang/josh-sync.
r? @ghost