New toolchain list format in 1.28.0 breaks Corrosion toolchain detection

[kanru]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

While testing the 1.28.0 beta I found my project with Corrosion reported error when invoking rustup

CMake Warning (dev) at build/_deps/corrosion-src/cmake/FindRust.cmake:363 (message):
  Unexpected output from `rustc --version` for Toolchain
  `stable-x86_64-unknown-linux-gnu`: ``.

  Ignoring this toolchain.
Call Stack (most recent call first):
  build/_deps/corrosion-src/cmake/Corrosion.cmake:63 (find_package)
  build/_deps/corrosion-src/CMakeLists.txt:73 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Rust Toolchain: 
CMake Error at build/_deps/corrosion-src/cmake/FindRust.cmake:23 (message):
  Could not find toolchain ''

  Available toolchains:

    `nightly-x86_64-unknown-linux-gnu`
    `nightly-2024-03-10-x86_64-unknown-linux-gnu`
    `1.70-x86_64-unknown-linux-gnu`
    `1.77-x86_64-unknown-linux-gnu`

Call Stack (most recent call first):
  build/_deps/corrosion-src/cmake/FindRust.cmake:469 (_findrust_failed)
  build/_deps/corrosion-src/cmake/Corrosion.cmake:63 (find_package)
  build/_deps/corrosion-src/CMakeLists.txt:73 (include)

Steps

1. Setup a minimum corrosion project https://corrosion-rs.github.io/corrosion/quick_start.html
2. Run cmake --build

Possible Solution(s)

Corrosion matches against the output of rustup toolchain list --verbose to find the toolchain path

https://github.com/corrosion-rs/corrosion/blob/master/cmake/FindRust.cmake#L337-L350

Either revert the rustup change, or Corrosion needs to detect the new output format. Though this will leave old projects broken.

Perhaps the new format can be (default) (active) instead of (active, default) to be more backwards compatible.

Notes

No response

Rustup version

rustup 1.28.0 (7ccf717e6 2024-12-23)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.83.0 (90b35a623 2024-11-26)`

Installed toolchains

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/kanru/.rustup

installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (active, default)
nightly-x86_64-unknown-linux-gnu
nightly-2024-03-10-x86_64-unknown-linux-gnu
1.70-x86_64-unknown-linux-gnu
1.77-x86_64-unknown-linux-gnu

active toolchain
----------------
name: stable-x86_64-unknown-linux-gnu
compiler: rustc 1.83.0 (90b35a623 2024-11-26)
active because: it's the default toolchain
installed targets:
  wasm32-unknown-unknown
  x86_64-unknown-linux-gnu

OS version

Fedora 41

[djc]

Maybe we should add a --message-format=json switch? And start by getting a fix into Corrosion?

[rami3l]

Maybe we should add a --message-format=json switch?

@djc We have #3434 to track this.

And start by getting a fix into Corrosion?

I do think fixing corrosion would be the right way to go, although should we also take into account old projects (with old corrosion) + old toolchains + new rustup, which will eventually break as @kanru has mentioned, or should we just warn the users if possible?

[rami3l]

Closing in favor of corrosion-rs/corrosion#590 and #4129, as it has become apparent that the real issue lies in the lack of a way to get the active toolchain's installation path.