Closed Mark-Simulacrum closed 2 years ago
calebcartwright
commented
2 years ago Looks like some conflicts stemming from the rustfmt version. I can land a subtree push in r-l/rustfmt later today if our current master is too far behind/contradicting with the latest internal rustc_* apis
Mark-Simulacrum
commented
2 years ago I'm not going to block on fixing CI here, it should be fine in rust-lang/rust I believe (based on locally checking with a relative path dep).
calebcartwright
commented
2 years ago I thought the tool builds in CI were still using the same dep specification as they are in the tool repo which is why I thought the PR checks in r-l/rust would fail with the same rustfmt errors when building rls, but either way, lmk if anything is needed on the rustfmt side of the equation
Mark-Simulacrum
commented
2 years ago No, we override rustfmt, cargo, and clippy to point at the in-tree versions when building in rust-lang/rust. There's not a great way to get that from outside the repository (I guess we could clone rust-lang/rust and add patches here....)
calebcartwright
commented
2 years ago What you describe definitely lines up with my understanding and recollection for the internal mod consumption, but I also recall times in the not too distant past where RLS was still consuming rustfmt via the crate from crates.io (and now the git repo reference) in those builds which was part of the complexity of in our update dances.
I must be remembering incorrectly however so no worries.
This inlines the upstream racer dependency as a subdirectory (no fancy submodule or subtree business, just a simple git clone and rm -rf racer/.git), and fixes the relevant bugs there which are blocking upstreaming.
In general this is expected to get us much closer to being able to self-fix breakage from rustc changes in this repository rather than needing to wait for a merge and crates.io publish of racer. Since the code isn't really changing upstream this doesn't come at any significant burden in terms of syncing changes.