-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking Issue for proc_macro_back_compat
#83125
Comments
I'm hitting this issue in glium/glium#1922 but there seems to be no use of the |
OH apparently it's a bug in the warning. The PR that added it didn't check for the crate but a dummy type. This dummy type is also present in rental. As rental still has thousands of downloads per day, maybe PR #83168 should be reverted until rental is fixed? |
Reverting that PR seems like overkill. I'll work on a fix for the false positive. |
@Aaron1011 that would do it as well, thanks! |
Interestingly enough, this is actually not a false-positive. When I disabled the pretty-printing hack, I got this panic:
which is the same type of issue that This means that The fact that |
@Aaron1011 I've filed a dedicated issue for it: #84428 |
If I resume, we didn't make the breaking when it was still early to do it so we did a hack and now time have passed and more people used the bugged behavior. Isn't the worst possible thing to do ? Better now than never I guess. |
Tried to compile Firefox and got TONS of such errors... 0:05.92 warning: using |
@andr0s Newer versions of the |
Firefox versions since 85 should not depend on offending cstr versions: https://bugzilla.mozilla.org/show_bug.cgi?id=1661961 @andr0s might be compiling the ESR version of Firefox. Latest ESR is 78.11.0. I've downloaded the source tarball and it still depends on According to the wiki, ESR 78.0 is still under maintenance until its last release on October 05. I think until then there should be no breakage of the build, and maybe one should wait a couple of weeks after that. Also I wonder if Firefox should maybe be integrated into crater. There is an issue for servo but none for Firefox proper or ESR, although it is an important product that builds on Rust. |
cc @jpernst I am using |
My project is a public crate so I can't just freeze the Rust version. I'm most likely just going to end up forking To reiterate, I am a single developer. Every unmaintained crate that is broken by removal of backward compatibility is yet another crate I have to maintain myself just so I can continue compiling my code. Dependencies cascade - the only logical end to this is that I have to take upon the sole burden of hundreds of crates, repeatedly updating them to keep up with the latest breakage in Rust. I would be spending more time fixing broken code in unfamiliar dependencies than actually being productive in my own work. Rust already has multiple strategies to try and avoid an "npm left-pad" situation, including keeping existing crates on crates.io and employing the Rust Editions. This whole thing about "this code won't compile in a future rustc" runs counter to all that, and I really hope that the Rust team is willing to consider alternatives. I have three questions:
|
Can you post the output you're getting from the compiler? |
|
Thanks! It looks like all of these warnings stem from the
As a member of the compiler team (and the person responsible for adding in several of the backward-compatibility hacks that we're now trying to remove), I recognize how disruptive these kinds of backwards-incompatible changes are to the ecosystem. We try to keep them to an absolute minimum, and features like To address your questions:
The rust/compiler/rustc_expand/src/base.rs Lines 1392 to 1396 in 09cb29c
rust/compiler/rustc_expand/src/proc_macro_server.rs Lines 893 to 898 in 09cb29c
rust/compiler/rustc_expand/src/proc_macro_server.rs Lines 941 to 942 in 09cb29c
From a language perspective, this is quite bad - the compiler's behavior shouldn't change just based on the name of the type you've written, or the filename you're using.
At the moment, there's no fixed timetable. The main reason that I'm trying to do this sooner rather than later is to prevent additional crates from beginning to rely on this behavior (which could make this even harder to remove in the future). The recent stabilization of
I'm committed to ensuring that the impact on the ecosystem is as small as possible. In particular, I want to make sure that we avoid the situation that you've just described, where individual crate authors are forced to fork arbitrary (transitive) dependencies to keep their project compiling. Before disabling any of these back-compat measures, I'll be performing another Crater run to gauge ecosystem impact, and (when possible) reaching out to affected projects on Github to explain what changes need to be made. Ideally, all affected downstream crates can simply run
Unfortunately, this would probably lead to a larger maintenance burden, since Cargo would need to be extended to allow passing this information along.
I don't think there's currently any such group, but I think it would be a good idea to form one. |
Thank you for the response. I'm feeling a bit better about this now. You mentioned that the warnings are only stemming from |
That's right - you can use |
@cosmicchipsocket you mix a lot of thing, true that breaking is disappointing, but archived repository is not rust compiler fault. with or without this you would end up with an unmaintained dependencies. So you are already in a situation with no upgrade cause of this dead crate. |
Rust's stability policy should ensure that an unmaintained crate will continue to compile with future versions of Rust (the crate itself may have bugs, but that's not caused by the compiler). This is a case where it's necessary for the compiler to violate that policy, but this kind of event should be very rare. In normal circumstances, users should be able to rely on the compiler not making breaking changes. |
@cosmicchipsocket I've opened #94063 to gauge the impact of starting to phase out one of these backwards-compatibility hacks (a hack that changes how we pretty-print certain types). It will still be applied to older versions of |
Your crate depends on an old version of `rental`, which relies on a backwards-compatibiltiy hack in rustc. In future versions of rustc, versions of `rental` below `0.5.6` will now compiling, breaking your crate. This PR updates your crate to `rental` 0.5.6, which ensures that it will continue to compile with both older and newer version of rustc. For more information, see rust-lang/rust#83125
Visited during compiler team tracking issue triage. Since #106060 is open and waiting on consensus to either flip the switch or land new tooling improvements, I'm marking this as |
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work.
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work.
Convert `proc_macro_back_compat` lint to an unconditional error. We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work. r? `@estebank`
…stebank Convert `proc_macro_back_compat` lint to an unconditional error. We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work. r? `@estebank`
…stebank Convert `proc_macro_back_compat` lint to an unconditional error. We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work. r? ``@estebank``
Rollup merge of rust-lang#125596 - nnethercote:rental-hard-error, r=estebank Convert `proc_macro_back_compat` lint to an unconditional error. We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work. r? ``@estebank``
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work.
What is this issue?
If you're a crate author who's been linked here, your crate (indirectly) depends on a version of a procedural macro crate that will stop compiling in the future. All affected crates have updated versions published, so you should update to the latest version of the crate mentioned by the compiler warning you saw.
Background
In the past, the Rust compiler has had several bugs in the way that it passes a
TokenStream
to procedural macros ('proc-macro's). Fixing these bugs resulted in changes the inputTokenStream
, which some proc-macros were not prepared to handle.To avoid breaking large portions of the ecosystem, several hardcoded hacks were added to the compiler. When specific macros from certain crates (e.g.
time-macros-impl
) are invoked, we invoke the macro with a modifiedTokenStream
(what would have been used before the bugfix), which keeps the project compiling.However, hard-coding specific crate and macro names in the compiler is a huge hack, which we'd like to remove as soon as possible. This issue tracks our progress towards removing all of these hacks.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
TODO
Unresolved Questions
Implementation history
The text was updated successfully, but these errors were encountered: