Rollup of 3 pull requests #132030
Merged
Rollup of 3 pull requests #132030
Conversation
This file contains 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
…Veykril fix: Fix CI running analysis-stats incorrectly against the standard libraries Fixes rust-lang/rust-analyzer#18326
…Veykril internal: Add more trivially `Sized` types to `is_sized` check
…Veykril Clamp Position::character to line length LSP says about Position::character > If the character value is greater than the line length it defaults back to the line length. but from_proto::offset() doesn't implement this. A client might for example request code actions for a whole line by sending Position::character=99999. I don't think there is ever a reason (besides laziness) why the client can't specify the line length instead but I guess we should not crash but follow protocol. Not sure how to update Cargo.lock (lib/README.md doesn't say how). Fixes rust-lang#18240
…calling-rustc, r=Veykril internal: fix lldb-dap unconditionally calling rustc Fixes rust-lang/rust-analyzer#18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place. I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
…-dependencies, r=lnicola vscode: update some dependencies I bumped Typescript and vsce; was a little tired of the warnings when running `vsce`.
LSP says about Position::character > If the character value is greater than the line length it defaults back to the line length. but from_proto::offset() doesn't implement this. A client might for example request code actions for a whole line by sending Position::character=99999. I don't think there is ever a reason (besides laziness) why the client can't specify the line length instead but I guess we should not crash but follow protocol. Technically it should be a warning, not an error but warning is not shown by default so keep it at error I guess. Fixes rust-lang#18240
…r=Veykril Clamp Position::character to line length 2/2 Completes rust-lang/rust-analyzer#18243 I don't think I have permissions to target this on the other PR, so we'll need to rebase manually
…lnicola internal: Fix editorconfig glob Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files. https://spec.editorconfig.org/#glob-expressions > {s1,s2,s3} > any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
Fix: Increase TOKEN_LIMIT in hir-expand Due to the `TOKEN_LIMIT`, rust-analyzer failed to expand macro for `web-sys::WebGl2RenderingContext` https://github.com/rustwasm/wasm-bindgen/blob/main/crates/web-sys/src/features/gen_WebGl2RenderingContext.rs <img width="780" alt="image" src="https://github.com/user-attachments/assets/3a39f18e-656e-43df-9994-0a0179fa42ac"> <img width="403" alt="image" src="https://github.com/user-attachments/assets/7ae8dcf9-a40a-4070-8623-dd3a953bbf45"> After increasing the `TOKEN_LIMIT`, the `web-sys::WebGl2RenderingContext` can be expanded successfully: <img width="459" alt="image" src="https://github.com/user-attachments/assets/76a71763-05a5-4f14-a5c9-61fc190c668f">
feat: initial support for safe_kw in extern blocks This PR adds initial support for `safe` keywords in external blocks. ## Changes 1. Parsing static declarations with `safe` kw and `unsafe` kw, as well as functions with `safe` kw in extern_blocks 2. Add `HAS_SAFE_KW ` to `FnFlags` 3. Handle `safe` kw in `is_fn_unsafe_to_call` query 4. Handle safe_kw in unsafe diagnostics
Update Cargo.lock
fix: classify `safe` as a contextual kw fix rust-lang#18352
…Veykril fix: Fix token downmapping failing for include! inputs Supercedes rust-lang/rust-analyzer#18325 Fixes rust-lang/rust-analyzer#18325 Fixes rust-lang/rust-analyzer#18313 Fixes rust-lang/rust-analyzer#18314
feat: better completions for extern blcoks This PR refactors `add_keywords` (making it much clearer!) and enhances completion for `extern` blocks. It is recommended to reviewing the changes in order of the commits: - The first commit (f3c4dde0a4917a2bac98605cc045eecfb4d69872) doesn’t change any logic but refactors parts of the `add_keywords` function and adds detailed comments. - The second commit (5dcc1ab649bf8a49cadf006d620871b12f093a2f) improves completion for `extern` kw and extern blocks.
minor: sync from downstream
coverage: Make counter creation handle node/edge counters more uniformly Similar to rust-lang#130380, this is another round of small improvements informed by my ongoing attempts to overhaul coverage counter creation. One of the big benefits is getting rid of the awkward special-case that would sometimes attach an edge counter to a node instead. That was needed by the code that chooses which out-edge should be given a counter expression, but we can avoid that by making the corresponding check a little smarter. I've also renamed several things to be simpler and more consistent, which should help with future changes.
Subtree update of `rust-analyzer` r? `@ghost`
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=3 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: f225713007 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (916e9ce): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.6%, secondary 2.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 781.092s -> 780.605s (-0.06%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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-analyzer#132029 (Subtree update ofrust-analyzer)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup