Skip to content
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

GCC/Rust build, rustc: 'error[E0658]: let...else statements are unstable' #3116

Open
tschwinge opened this issue Aug 3, 2024 · 2 comments
Open
Assignees

Comments

@tschwinge
Copy link
Member

This already was mentioned a while ago in https://inbox.sourceware.org/[email protected] "Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)", but as of the 2024-08-01 push of GCC/Rust changes to GCC upstream (#2965 "[upstream] 2024-04-23"), I'm now no longer able to build GCC/Rust on one of my standard testing systems:

[...]
make[3]: Entering directory '[...]/build-gcc/libgrust/libformat_parser'
cargo \
  --config [...]/source-gcc/libgrust/libformat_parser/.cargo/config \
  build \
    --offline \
    --target-dir . \
    --manifest-path [...]/source-gcc/libgrust/libformat_parser/Cargo.toml \
    # FIXME: Not always '--release', right?
   Compiling generic_format_parser v0.1.0 ([...]/source-gcc/libgrust/libformat_parser/generic_format_parser)
error[E0658]: `let...else` statements are unstable
   --> generic_format_parser/src/lib.rs:994:5
    |
994 | /     let Some(unescaped) = unescape_string(snippet) else {
995 | |         return InputStringKind::NotALiteral;
996 | |     };
    | |______^
    |
    = note: see issue #87335 <https://github.com/rust-lang/rust/issues/87335> for more information

For more information about this error, try `rustc --explain E0658`.
error: could not compile `generic_format_parser` due to previous error
make[3]: *** [Makefile:431: debug/liblibformat_parser.a] Error 101
[...]

This is Debian GNU/Linux 12 (bookworm):

$  apt-cache madison cargo rustc
     cargo | 0.66.0+ds1-1 | http://deb.debian.org/debian bookworm/main ppc64el Packages
     cargo | 0.66.0+ds1-1 | http://deb.debian.org/debian bookworm/main Sources
     rustc | 1.63.0+dfsg1-2 | http://deb.debian.org/debian bookworm/main ppc64el Packages
     rustc | 1.63.0+dfsg1-2 | http://deb.debian.org/debian bookworm/main Sources

Is there (a) any (reasonable) way to keep the GCC/Rust build working with that version of rustc, and/or (b) what is the minimum versions of cargo and rustc that GCC/Rust requires? Let's please document this in gcc/doc/install.texi, as, for example, @rorth had also been requesting in https://inbox.sourceware.org/[email protected] "Re: [PATCH] build: Check for cargo when building rust language".

Aha, and in that latter thread, in the next message by @CohenArthur: "We currently depend on Rust version 1.72", but "The goal is to reduce that Rust version further soon anyway - we are going to target Rust version 1.49" -- which would resolve my issue. What's the status of that?


I understand correctly this issue is different from the recent https://gcc-rust.zulipchat.com/#narrow/stream/266897-general/topic/rustc.20nightly.20needed.20by.20default "rustc nightly needed by default" discussion, #3101 "Remove dependency on nightly Rust", which resolved the requirement of an even-newer (nightly) version of rustc?

@tschwinge
Copy link
Member Author

I have two small WIP patches to make this work; will share later. 😄

@cooljeanius
Copy link
Contributor

(b) what is the minimum versions of cargo and rustc that GCC/Rust requires? Let's please document this in gcc/doc/install.texi, as, for example, @rorth had also been requesting in inbox.sourceware.org/[email protected] "Re: [PATCH] build: Check for cargo when building rust language".

Yeah, the cargo requirement in particular is a major problem, as a lot of the machines on GCC's compile farm are either missing it entirely, or have a version that doesn't recognize the --config flag...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants