-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add span to group. #14960
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
Add span to group. #14960
Conversation
This will have to wait for the the next subtree sync, that is also the reason why you ran into those weird problems |
Ah, makes sense. Would it be better to just submit this in rust instead? |
No, we want as little changes in the upstream subtree as possible. We are just lacking behind with the syncs atm because of problems we had at our end. We might be able to sync next week again, then we can merge this. |
Subtree sync was done yesterday, can you rebase? |
(wanna check if #14994 (comment) works now since this PR should trigger it) |
Add span to group. This appears to fix #14959, but I've never contributed to rust-analyzer before and there were some things that confused me: - I had to add the `fn byte_range` method to get it to build. This was added to rust in [April](rust-lang/rust#109002), so I don't understand why it wasn't needed until now - When testing, I ran into the fact that rust recently updated its `METADATA_VERSION`, so I had to test this with nightly-2023-05-20. But then I noticed that rust has its own copy of `rust-analyzer`, and the metadata version bump has already been [handled there](rust-lang/rust@60e95e7). So I guess I don't really understand the relationship between the code there and the code here.
💔 Test failed - checks-actions |
Ok, rebased and I also added a flag for overriding the proc-macro-srv binary, without which these changes are hard to test. |
Turns out one of the tests that never got executed wasnt updated #14995 |
It looks like the CI failure is caused by nightly distributing a broken rust-analyzer-proc-macro-srv. On my system, I get
|
@bors r+ |
Add span to group. This appears to fix #14959, but I've never contributed to rust-analyzer before and there were some things that confused me: - I had to add the `fn byte_range` method to get it to build. This was added to rust in [April](rust-lang/rust#109002), so I don't understand why it wasn't needed until now - When testing, I ran into the fact that rust recently updated its `METADATA_VERSION`, so I had to test this with nightly-2023-05-20. But then I noticed that rust has its own copy of `rust-analyzer`, and the metadata version bump has already been [handled there](rust-lang/rust@60e95e7). So I guess I don't really understand the relationship between the code there and the code here.
💔 Test failed - checks-actions |
@bors r+ |
💡 This pull request was already approved, no need to approve it again.
|
Add span to group. This appears to fix #14959, but I've never contributed to rust-analyzer before and there were some things that confused me: - I had to add the `fn byte_range` method to get it to build. This was added to rust in [April](rust-lang/rust#109002), so I don't understand why it wasn't needed until now - When testing, I ran into the fact that rust recently updated its `METADATA_VERSION`, so I had to test this with nightly-2023-05-20. But then I noticed that rust has its own copy of `rust-analyzer`, and the metadata version bump has already been [handled there](rust-lang/rust@60e95e7). So I guess I don't really understand the relationship between the code there and the code here.
💔 Test failed - checks-actions |
(sorry for the spam, but this PR is special in that it triggers a nightly build which we are having problmes with right now) |
Add span to group. This appears to fix #14959, but I've never contributed to rust-analyzer before and there were some things that confused me: - I had to add the `fn byte_range` method to get it to build. This was added to rust in [April](rust-lang/rust#109002), so I don't understand why it wasn't needed until now - When testing, I ran into the fact that rust recently updated its `METADATA_VERSION`, so I had to test this with nightly-2023-05-20. But then I noticed that rust has its own copy of `rust-analyzer`, and the metadata version bump has already been [handled there](rust-lang/rust@60e95e7). So I guess I don't really understand the relationship between the code there and the code here.
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
… r=Veykril Don't provide `add_missing_match_arms` assist when upmapping match arm list failed Fixes #15310 We shouldn't provide the assist when we fail to find the original match arm list. Note that this PR will temporarily make the assist not applicable when attribute macro operates on the match expression in question, just like the case in #15310, for most of the current stable toolchain users. This is because the sysroot-abi proc-macro-srv on the current stable [discards] spans for `Group` delimiters in some code paths, which the popular `proc-macro2` crate almost always calls, and it makes the identity of match arm list's brackets lost, leading to the upmapping failure. This has been fixed by #14960, which will land in the next stable, 1.71. [discards]: https://github.com/rust-lang/rust/blob/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/src/tools/rust-analyzer/crates/proc-macro-srv/src/abis/abi_sysroot/ra_server.rs#L231
This appears to fix #14959, but I've never contributed to rust-analyzer before and there were some things that confused me:
fn byte_range
method to get it to build. This was added to rust in April, so I don't understand why it wasn't needed until nowMETADATA_VERSION
, so I had to test this with nightly-2023-05-20. But then I noticed that rust has its own copy ofrust-analyzer
, and the metadata version bump has already been handled there. So I guess I don't really understand the relationship between the code there and the code here.