dtolnay / proc-macro2

Apache License 2.0
739 stars 117 forks source link

Missed nightly feature `proc_macro_byte_character` #451

Closed boozook closed 6 months ago

boozook commented 6 months ago

Crate: 1.0.80 Rustc: 1.79.0-nightly (8df7e723e 2024-03-30)

error[E0658]: use of unstable library feature 'proc_macro_byte_character'
   --> /Users/u/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.80/src/wrapper.rs:871:21
    |
871 |                     proc_macro::Literal::byte_character(byte)
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #115268 <https://github.com/rust-lang/rust/issues/115268> for more information
    = help: add `#![feature(proc_macro_byte_character)]` to the crate attributes to enable
    = note: this compiler was built on 2024-03-30; consider upgrading it if it is out of date

I suppose there should be crate attribute:

#![cfg_attr(not(no_literal_byte_character), feature(proc_macro_c_str_literals))]

Probably this is not a problem because proc_macro_c_str_literals was stabilised nearly, so 🤷🏻‍♂️.

mikkelens commented 6 months ago

This being missing makes me unable to use arduino-hal templates with cargo generate because their dependencies use this crate through quote, and using stable is not an option for this. I'm trying to figure out how to force transitive dependencies to use 1.0.35 of quote or 1.0.79 of proc-macro2, but simply specifying it for cargo with a cargo update -p proc-macro2 --precise 1.0.79 does not do it.

dtolnay commented 6 months ago

It looks like you are using an old nightly compiler. In general, old nightly compilers are not supported. The expectation is that if you are using a nightly toolchain, then you are remaining on top of recent nightly changes.

If you need to pin to an old nightly toolchain, then you would need to use corresponding old crate versions, too (such as via a lockfile).

mikkelens commented 6 months ago

The avr-hal templates for arduino, aka. arduino-hal templates, use a rust-toolchain.toml file to specify specific versions of nightly similar to what you describe, but like you imply, they use an older version of nightly (in my case: 2024-03-22). Anyways, I was able to solve the issue by adding this to my my Cargo.toml, which ends up modifying my "lockfile" (assuming you are refering to Cargo.lock):

[patch.crates-io]
proc-macro2 = { git = "https://github.com/dtolnay/proc-macro2", rev = "4ba4ab1ec52d9e8286826a898430683ba002a002" }
mikkelens commented 6 months ago

Actually, thinking about it, the version in rust-toolchain.toml is probably infered from current latest installed nightly, and I updated nightly only after generating the template today. Sorry for the confusion.

Rahix commented 6 months ago

@dtolnay Just to provide some context, the reason we pin older nightlies for Rust on AVR is that there are compiler regressions in the AVR backend from time to time. This has two implications:

  1. When a regression is present, there simply is no way to use latest nightly.
  2. When no known regressions are present, we still want to advertise a known-to-work compiler version so unsuspecting users aren't the first ones to run into new problems.

Such is the life of a tier 3 target...

In general, old nightly compilers are not supported. The expectation is that if you are using a nightly toolchain, then you are remaining on top of recent nightly changes.

This is a bit unfortunate, as for the stated reason, we A) cannot always upgrade nightly and B) this makes regression-hunting quite difficult if certain crates break with not-that-old compiler versions.

then you would need to use corresponding old crate versions, too (such as via a lockfile).

This is a good pointer though, I guess we can try doing that for crates that are AVR-specific. This of course won't work as soon as any non-platform-specific crate in the dependency tree pulls in later versions...

Rahix commented 6 months ago

Actually, thinking about it, the version in rust-toolchain.toml is probably infered from current latest installed nightly

@mikkelens No, it is not. It is hard-coded here and we update it when we have a new known-to-work compiler version.