Is (cross-)compiling with an "alt" compiler and "non-alt" standard library supported?

[SimonSapin]

#39754 added “alternate” builds for a small number of platforms. They disable LLVM assertions, significantly improving compile times compared to Nightly. More background: https://internals.rust-lang.org/t/disabling-llvm-assertions-in-nightly-builds/5388

Servo uses these by default when available. Them being only available for a small number of platforms is ok because that covers platforms most developers use, and we can fall back to "normal" slower Nightly compilers.

In #42967 we ran into an issue that only occurred on OS X, when compiling crates that depend on procedural macro crates, when using an "alt" compiler with a "non-alt" standard library. It seems in theory that enabling or disabling LLVM assertions in rustc should not have any effect on standard libraries, but we worked around that issue in servo/servo#17575 by making sure we download an std of the same kind as rustc.

It gets tricky when cross-compiling (for example to Android), since "alt" standard libraries are not necessarily available for the target platform even when they are for the host. In servo/servo#17604 we might need to rewrite our mach configuration handling and Rust bootstrapping to be able to support selecting an "alt" vs "non-alt" compiler depending on the cross-compilation target.

But do we really need to? Or is #42967 a rustc bug after all? "Should" it work to use an "alt" rustc with "non-alt" std?

CC @aturon since I don’t know are the appropriate people to ask, please redirect.

[metajack]

cc @jonathandturner

[SimonSapin]

Disabling LLVM assertions in Nightly would make this whole issue go away since alternate compiler builds would become unnecessary.

[Mark-Simulacrum]

cc @alexcrichton

[alexcrichton]

I believe the tl;dr; is basically "no, this is not a supported configuration". The intention was that these builds would be for developer-only machines which didn't need the full power of the rest of the toolchain.

[SimonSapin]

Developers working on platform-specific issues or features need to cross-compile. We don’t need full toolchains for target (as opposed to host) platforms, only std.

We can probably rework bootstrapping on our side so that "non-alt" builds are used for cross-compiling, but if fixing #42967 on the rustc side is reasonably feasible that would be nicer.

[sophiajt]

@SimonSapin - iirc, the way alt builds were added was kind of a hack to begin with, intended as a way to get Servo a build without assertions. It was acknowledged at the time it wasn't the best solution, but we hoped that it would be good enough.

It sounds like we're saying now that the hack didn't end up being good enough. If that's the case, sounds like we should get people together again to see if we can come up with another solution.

[SimonSapin]

I’m not sure “not good enough” applies. There is one known issue. I don’t know if that makes the whole approach flawed or if it’s “just” a bug/regression that can be fixed.

(Specifically, when loading a procedural macro crate, the hash/filename expected by that crate for std didn’t match the one available on disk. On OS X only.)

[sophiajt]

@alexcrichton - is there a way to address this hash/filename issue on macOS? Is it possible it's just a bug that hasn't gotten fixed yet?

[SimonSapin]

I bisected #42967. I can reproduce it in dfa7e21 but not in e40ef96, leaving #42433 as the only change.

[SimonSapin]

That PR adds --enable-profiler to the configuration of most builds but not "alternate" ones. Could that affect the hash of std? Is there a reason not to? I think enabling it everywhere might fix the issue.

[SimonSapin]

Opened #43167