Mega-sync from rust-lang/rust
#13676
Conversation
…and-pms-component
This removes some RPC when creating and emitting diagnostics, and simplifies the bridge slightly. After this change, there are no remaining methods which take advantage of the support for `&mut` references to objects in the store as arguments, meaning that support for them could technically be removed if we wanted. The only remaining uses of immutable references into the store are `TokenStream` and `SourceFile`.
…nother-type, r=estebank Point at a type parameter shadowing another type This patch fixes a part of #97459.
proc_macro/bridge: send diagnostics over the bridge as a struct This removes some RPC when creating and emitting diagnostics, and simplifies the bridge slightly. After this change, there are no remaining methods which take advantage of the support for `&mut` references to objects in the store as arguments, meaning that support for them could technically be removed if we wanted. The only remaining uses of immutable references into the store are `TokenStream` and `SourceFile`. r? `@eddyb`
This fixes a typo first appearing in #94624 in which test-macro diagnostic uses "a" article twice. Since I searched sources for " a a " sequences, I also fixed the same issue in a few source files where I found it. Signed-off-by: Petr Portnov <gh@progrm-jarvis.ru>
initial josh subtree sync This demonstrates what a josh-based rustup would look like with my patched josh. To create it I did ``` git fetch http://localhost:8000/rust-lang/rust.git:start=75dd959a3a40eb5b4574f8d2e23aa6efbeb33573[:prefix=src/tools/miri]:/src/tools/miri.git master git merge FETCH_HEAD ./rustup-toolchain HEAD && ./miri fmt git commit -am rustup ``` Unlike the [previous attempt](rust-lang/miri#2554), this does not add a new root commit to the repo. Once we merge this, we committed to using josh for subtree syncing, and in particular a version of josh that includes josh-project/josh#961 (or something compatible).
It's easy to just use `unescape_literal` + `byte_from_char`.
Unescaping cleanups Some code improvements, and some error message improvements. Best reviewed one commit at a time. r? ````@matklad````
⬆️ rust-analyzer r? ``@ghost``
rustbot
added
the
S-waiting-on-review
|
Thank you very much for spending the time looking into this! (both of you :) ) r? @lnicola |
|
One issue I have with this is not being able to exclude commits. For example, I don't know if 3a1aa37 is something we want, but I understand how it happened downstream. There's one more thing I want to try, i guess I'll be able to say more afterwards. But thanks for spending time on this. |
Looks like a drive-by fix that happened in rust-lang/rust#100643 I think the right time to review these changes is before they get merge into rust-lang/rust — I'm sure they have automated rules to notify a group of people if a certain path is touched, that seems like a good idea. I would advise simply reverting that change in I don't think we can get both of "pick which commits we like" and "sync seamlessly back and forth". The former seems like an organizational problem the rust project has tools for. |
|
to set up maintainer notifications you can add yourself to the |
Please do not exclude commits, it's very important for the sync continuity that you never edit/rebase/remove commits generated by You can always do I would suggest swiftly merging this PR (after reverting whatever unwanted changes, tho if tests pass that can be done later too) to bring the two repos in sync once more, after which weekly syncs can resume as normal. (The current state of the PR is non-negotiable for allowing the subtree workflow, but we're talking about the commit graph here not the changes, which can be adjusted as-needed - e.g. adding revert commits to PR would result in the next RA -> |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
notify the rust-analyzer team on changes to the rust-analyzer subtree As proposed in rust-lang/rust-analyzer#13676 (comment)
notify the rust-analyzer team on changes to the rust-analyzer subtree As proposed in rust-lang/rust-analyzer#13676 (comment)
This essentially implements @oli-obk's suggestion here #13459 (comment), with @eddyb's help.
This PR is equivalent to 14 syncs (back and forth) between
rust-lang/rustandrust-lang/rust-analyzer.Working from this list (from bottom to top):
(This listed was assembled by doing a
git subtree push, which made a branch, and looking at the new commits in that branch, picking only those that were:arrow_up: rust-analyzercommits)We used the following commands to simulate merges in both directions:
We encountered no merge conflicts that Git wasn't able to solve by doing it this way.
Here's what the commit graph looks like (as shown in the Git Lens VSCode extension):
This PR closes #13459
Does this unbreak
rust->rasyncs?Yes, here's how we tried:
In
rust-analyzer:subtree-fix(this PR's branch)git checkout -b subtree-fix-merge-testgit merge masterIn
rust:git checkout -b test-changesrc/tools/rust-analyzer/Cargo.toml)git subtree push -P src/tools/rust-analyzer ra-local final-sync(this follows the Clippy sync guide)This created a
final-syncbranch inrust-analyzer.In
rust-analyzer:git merge --no-ff final-sync(this follows the Clippy sync guide)Now
git loginrust-analyzershows this:And
git diff 0513fc02a08ea9de952983624bd0a00e98044b36shows this:Does this unbreak
ra->rustsyncs?Yes, here's how we tried.
From
rust:git checkout -b sync-from-ragit subtree pull -P src/tools/rust-analyzer ra-local subtree-fix-merge-test(this is adapted from the Clippy sync guide, you would normally usera-upstream masterbut we're simulating things here)A commit editor pops up, there was no merge conflicts.
How do we prevent this from happening again?
Like @bjorn3 said in #13459 (comment)
But if we get it wrong again, at least now we have a not-so-painful way to fix it.