-
Notifications
You must be signed in to change notification settings - Fork 909
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Bumping syntax-ap crates fails due to reduced visiblities #3903
Comments
This looks like it may be tricky. Do you know the first/earliest version of rustc-ap that supports IIRC rustfmt 1.4.9 is using 606 and the latest on master has been bumped to 610, but the visibility changes in 626 appear very problematic |
@josephlr Thank you for the report. I am aware of the visibility issue, and was planning to fix the issue once he refactoring thing has settled. We need to re-export everything we need in the libsyntax, adding comments to make sure they won't become private or removed in the future. |
@topecongiro IIUC this will block updating currently broken RLS. |
@josephlr @mati865 if it helps you, the latest version that doesn't have rust-lang/rust@c189565 yet is 615, and the latest version that doesn't have rust-lang/rust@742ec4b either is 612. efiapi was merged much later in rust-lang/rust@2dd4e73 (earliest rustc-ap-syntax version is 626) |
@mati865 I do not think this is blocking the broken RLS as AFAIK RLS does not directly depend on rustc-ap-* crates. |
For anyone interested in tackling this issue, here are the instructions:
|
This is blocked by alexcrichton/rustc-auto-publish#14. cc @calebcartwright. |
@rchaser53 are you working on this one too? (asking based on rust-lang/rust#67653). I've got a good chunk of the changes made locally, mostly waiting to see how the new librustc_parse crate will become available. If you're further along though I'm happy to stop and let you take it, just want to make sure we aren't duplicating efforts! |
Oh sorry😅 |
…ities, r=Centril restore some rustc_parse visibilities for rustfmt In rust-lang@c189565 some visibilities were reduced on the parse mod (which now resides in the rustc_parse crate) as part of some refactoring and splitting up of libsyntax. However, rustfmt needs access to a few of those items that are no longer visible. This restores the visibility on those items rustfmt depends on. rust-lang/rustfmt#3903 (comment) rust-lang/rustfmt#4009 cc @topecongiro
…ities, r=Centril restore some rustc_parse visibilities for rustfmt In rust-lang@c189565 some visibilities were reduced on the parse mod (which now resides in the rustc_parse crate) as part of some refactoring and splitting up of libsyntax. However, rustfmt needs access to a few of those items that are no longer visible. This restores the visibility on those items rustfmt depends on. rust-lang/rustfmt#3903 (comment) rust-lang/rustfmt#4009 cc @topecongiro
…ities, r=Centril restore some rustc_parse visibilities for rustfmt In rust-lang@c189565 some visibilities were reduced on the parse mod (which now resides in the rustc_parse crate) as part of some refactoring and splitting up of libsyntax. However, rustfmt needs access to a few of those items that are no longer visible. This restores the visibility on those items rustfmt depends on. rust-lang/rustfmt#3903 (comment) rust-lang/rustfmt#4009 cc @topecongiro
@topecongiro - this can be closed with #4043 being merged |
Closed via #4043 |
I'm trying to fix rust-osdev/uefi-rs#104 (comment). Rustfmt needs a new engough
syntax
to support"efiapi"
. I tired to do what #3870 did and bumprustc-ap-syntax
to version626
.This caused a very large number of compiler errors. Some of them are caused by small changes like: rust-lang/rust@742ec4b, which are easy enough to fix. However, others errors are caused by changes like rust-lang/rust@c189565 that make a bunch of
libsyntax
's functionality private.What should I do here? Should the
libsyntax
commits be reverted in the main rust-lang/rust repo?CC: @Centril
The text was updated successfully, but these errors were encountered: