-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 #108260
⬆️ rust-analyzer #108260
Conversation
Discard postfix completion if the next_non_trivia_sibling of dot_token is an ELSE_KW.
Looks like this is a native encoding for Emacs at least!
minor: sync from downstream
…indivisble-expr, r=Veykril fix: Don't trigger postfix completion in `if` block which has an `else` block Fix rust-lang#14096
…verflow, r=Veykril fix: Don't expand macros in the same expansion tree after overflow This patch fixes 2 bugs: - In `Expander::enter_expand_id()` (and in code paths it's called), we never check whether we've reached the recursion limit. Although it hasn't been reported as far as I'm aware, this may cause hangs or stack overflows if some malformed attribute macro is used on associated items. - We keep expansion even when recursion limit is reached. Take the following for example: ```rust macro_rules! foo { () => {{ foo!(); foo!(); }} } fn main() { foo!(); } ``` We keep expanding the first `foo!()` in each expansion and would reach the limit at some point, *after which* we would try expanding the second `foo!()` in each expansion until it hits the limit again. This will (by default) lead to ~2^128 expansions. This is essentially what's happening in rust-lang#14074. Unlike rustc, we don't just stop expanding macros when we fail as long as it produces some tokens so that we can provide completions and other services in incomplete macro calls. This patch provides a method that takes care of recursion depths (`Expander::within_limit()`) and stops macro expansions in the whole macro expansion tree once it detects recursion depth overflow. To be honest, I'm not really satisfied with this fix because it can still be used in unintended ways to bypass overflow checks, and I'm still seeking ways such that misuses are caught by the compiler by leveraging types or something. Fixes rust-lang#14074
Co-authored-by: Stig Brautaset <stig@brautaset.org>
Support UTF-32 position encoding Looks like this is a native encoding for Emacs at least!
…, r=Veykril fix: Search raw identifiers without prefix When we find references/usages of a raw identifier, we should disregard `r#` prefix because there are keywords one can use without the prefix in earlier editions (see rust-lang#13034; this bug is actually fallout from the PR). `name`, the text we're searching for, has already been stripped of the prefix, but the text of nodes we compare it to hasn't been. The second commit is strictly refactoring, I can remove it if it's not much of value.
internal: Improve parser recovery for delimited lists Closes rust-lang/rust-analyzer#11188, rust-lang/rust-analyzer#10410, rust-lang/rust-analyzer#10173 Should probably be merged after the stable release as this might get the parser stuck if I missed something
Don't assume VSCode internal commands in the server
Bump lsp-types
…nly of `None` args
internal: Don't allocate the generic_args vec in `hir_def::Path` if it consists only of `None` args Saves roughly 5mb on self
internal: Make CompletionItem more POD-like
Some changes occurred in src/tools/rust-analyzer cc @rust-lang/wg-rls-2 |
@fasterthanlime umm, bit of help here please, do you know why this PR (as produced by |
Off the top of my head (and from my phone) I'm not sure. That one is the only older commit (Jan 11), right? 3e0e51c - Everything else is from a month later at least, afaict. It corresponds to rust-lang/rust-analyzer@3e0e51c in RA, which seems to have been introduced with rust-lang/rust-analyzer#14143 — I'm not sure how it ended up there, but it seems git-subtree is doing the right thing? edit: I'm still confused after checking it out a little more (still on mobile). That commit is already in rust as 40ba0e8 - @eddyb is it possible that's the one commit we messed up when manually making the mega-sync? |
@lnicola so I can't really explain what happened there unfortunately. However, I'm curious: if you do another rust->ra sync after this PR (you can pretend to do that without actually merging the PR through bors/GitHub's UI), does the next ra->rust sync also still contain this commit? |
This is how I tested: # in the RA repo
$ git branch -D sync-from-rust
# in the Rust repo
$ git checkout rust-analyzer-2023-02-20
$ git subtree push -P src/tools/rust-analyzer rust-analyzer-local sync-from-rust
$ git checkout -b ra-new-sync
$ git subtree pull -P src/tools/rust-analyzer rust-analyzer-local sync-from-rust
$ git log --format=oneline
04c4eda971e945fa533880eb14fc6db314d8ed3e (HEAD -> ra-new-sync) Merge commit '7e711da2f07778d62f6411de5da520f1e260d761' into ra-new-sync
03288ebba35defc807952e6e55a0ab8f5f77aa83 (origin/rust-analyzer-2023-02-20, rust-analyzer-2023-02-20) :arrow_up: rust-analyzer
7e711da2f07778d62f6411de5da520f1e260d761 (rust-analyzer-local/sync-from-rust) :arrow_up: rust-analyzer
824f915cbc32c0942122389274a1b6fbe2ffc51e (upstream/master, upstream/HEAD, master) Auto merge of #108235 - tmiasko:read-buf, r=the8472
[snip] |
Okay well, it doesn't seem to show up again. Here's what I don't understand about the current situation:
These paths don't show up in the Files changed tab of the PR, so I'm really not sure what's going on. |
Given that my test above went fine, should we merge it like this? |
The test working makes me slightly more confident in this, ideally I'd love to have an extra pair of eyes on this, I've pinged a couple folks and will keep you posted |
I haven't heard back yet and don't want to block this, you got my 👍 |
Based on my subtree experiences, I think it's fine. Sometimes a commit gets confusingly replayed on the other side of the subtree so git can't quite be sure if it's new or not. If it's only one in a hundred commits or so, it's annoying but not unexpected. |
@bors r+ p=1 |
☀️ Test successful - checks-actions |
Finished benchmarking commit (5243ea5): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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. |
r? @ghost