proc-macro-error2 2.0.1 will become a hard error and its upstream is archived, so no bump is coming #119

Open
opened 2026-08-25 08:06:33 +00:00 by jlxq0 · 0 comments
Owner

cargo build and cargo clippy both report, informationally and at exit 0:

warning: the following packages contain code that will be rejected by a
future version of Rust: proc-macro-error2 v2.0.1

Nothing fails today. It is recorded because the failure mode is #112's: the tree goes red with nobody having touched the code, and the diagnosis lands in whatever pull request happens to be open when rustc makes the change.

What it is

cargo report future-incompatibilities --id 1:

warning[E0365]: extern crate `proc_macro` is private and cannot be re-exported
   --> proc-macro-error2-2.0.1/src/lib.rs:494:13
    |
494 |     pub use proc_macro;
    |
    = warning: this was previously accepted by the compiler but is being
      phased out; it will become a hard error in a future release!
    = note: for more information, see issue #127909

How it reaches us

Two paths, both transitive under matrix-sdk 0.17, neither a direct dependency of ours (cargo tree -i proc-macro-error2 --all-features):

proc-macro-error2 v2.0.1
├── aquamarine v0.6.0 (proc-macro)
│   ├── matrix-sdk v0.17.0
│   └── matrix-sdk-crypto v0.17.0
└── matrix-pickle-derive v0.2.2 (proc-macro)
    └── matrix-pickle v0.2.2
        └── vodozemac v0.10.0

There is no version to bump to, and there will not be one

2.0.1 is max_stable_version on crates.io and the only 2.x release. cargo update -p proc-macro-error2 locks 0 packages.

The upstream repository is archived. github.com/GnomedDev/proc-macro-error-2: "This repository was archived by the owner on Jun 7, 2026. It is now read-only." Its issue #13, "Crate emits future incompatibility warning", is open and will stay open; so is #17, "Is this crate maintained?".

So "wait for upstream" is not a plan, and it is the plan everyone will assume is in place until someone checks. That is the reason this is written down rather than left in a build log.

Options, none urgent

  1. Wait for matrix-sdk and vodozemac to drop it. Costs nothing and is the likeliest resolution: both dependents are proc-macro crates, and aquamarine only draws diagrams in rustdoc. Risk is that the rustc change lands first.
  2. [patch.crates-io] onto a fork with the one-line fix (pub extern crate proc_macro;). Buys certainty at the cost of carrying a fork of a build-time dependency of a dependency.
  3. Nothing, deliberately, having recorded it. Defensible while the warning is informational.

Not proposed: suppressing the warning. It is the only signal we would get.

Acceptance

Not "the warning is gone" — it will go on its own when a dependent drops the crate, and that is a fine outcome.

Either a cargo tree -i proc-macro-error2 that finds nothing after a dependency bump, or a decision recorded here with the date and the reasoning. Re-check on the next matrix-sdk bump; cargo tree -i proc-macro-error2 --all-features is the one command, and empty output is the answer.

Provenance

Surfaced in every local gate run during the v0.10.4 work on 2026-08-25 and flagged by the release worker. Recorded rather than remembered, on the same argument as #112.

`cargo build` and `cargo clippy` both report, informationally and at exit 0: warning: the following packages contain code that will be rejected by a future version of Rust: proc-macro-error2 v2.0.1 Nothing fails today. It is recorded because the failure mode is #112's: the tree goes red with nobody having touched the code, and the diagnosis lands in whatever pull request happens to be open when rustc makes the change. ## What it is `cargo report future-incompatibilities --id 1`: warning[E0365]: extern crate `proc_macro` is private and cannot be re-exported --> proc-macro-error2-2.0.1/src/lib.rs:494:13 | 494 | pub use proc_macro; | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #127909 ## How it reaches us Two paths, both transitive under `matrix-sdk 0.17`, neither a direct dependency of ours (`cargo tree -i proc-macro-error2 --all-features`): proc-macro-error2 v2.0.1 ├── aquamarine v0.6.0 (proc-macro) │ ├── matrix-sdk v0.17.0 │ └── matrix-sdk-crypto v0.17.0 └── matrix-pickle-derive v0.2.2 (proc-macro) └── matrix-pickle v0.2.2 └── vodozemac v0.10.0 ## There is no version to bump to, and there will not be one `2.0.1` is `max_stable_version` on crates.io and the only 2.x release. `cargo update -p proc-macro-error2` locks 0 packages. **The upstream repository is archived.** `github.com/GnomedDev/proc-macro-error-2`: *"This repository was archived by the owner on Jun 7, 2026. It is now read-only."* Its issue #13, "Crate emits future incompatibility warning", is open and will stay open; so is #17, "Is this crate maintained?". So "wait for upstream" is not a plan, and it is the plan everyone will assume is in place until someone checks. That is the reason this is written down rather than left in a build log. ## Options, none urgent 1. **Wait for `matrix-sdk` and `vodozemac` to drop it.** Costs nothing and is the likeliest resolution: both dependents are proc-macro crates, and `aquamarine` only draws diagrams in rustdoc. Risk is that the rustc change lands first. 2. **`[patch.crates-io]` onto a fork with the one-line fix** (`pub extern crate proc_macro;`). Buys certainty at the cost of carrying a fork of a build-time dependency of a dependency. 3. **Nothing, deliberately, having recorded it.** Defensible while the warning is informational. Not proposed: suppressing the warning. It is the only signal we would get. ## Acceptance Not "the warning is gone" — it will go on its own when a dependent drops the crate, and that is a fine outcome. Either a `cargo tree -i proc-macro-error2` that finds nothing after a dependency bump, or a decision recorded here with the date and the reasoning. Re-check on the next `matrix-sdk` bump; `cargo tree -i proc-macro-error2 --all-features` is the one command, and empty output is the answer. ## Provenance Surfaced in every local gate run during the `v0.10.4` work on 2026-08-25 and flagged by the release worker. Recorded rather than remembered, on the same argument as #112.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlxq0/matrix-mcp#119
No description provided.