x test compiler/rustc_codegen_{cranelift,gcc} is not supported

[jyn514]

thread 'main' panicked at 'error: no rules matched compiler/rustc_codegen_cranelift', src/bootstrap/builder.rs:286:17
thread 'main' panicked at 'error: no rules matched compiler/rustc_codegen_gcc', src/bootstrap/builder.rs:286:17

cc @bjorn3 @antoyo - are there any tests for these crates that make sense in-tree? I first noticed this because it means x test compiler/* breaks, but if that's something I have to live with I can, it would just be nice for it to work.

@rustbot label: +A-rustbuild +A-codegen

[bjorn3]

For cg_clif there are tests that make sense in-tree I think. However I want to first rewrite my test code from shell scripts to rust before wiring it up to rustbuild. Also I'm not quite sure yet how to actually run the tests when cg_clif is built using rustbuild rather than cg_clif's own build system (which duplicates some of the functionality of rustbuild).

[jyn514]

Sounds good :) I'm happy to help with the "wire it up to rustbuild" part.

[jyn514]

@rustbot label +S-blocked

(waiting for bjorn3 to rewrite his shell scripts before spending too much time on this)

[jyn514]

@antoyo what are your thoughts on running test.sh in-tree? I ran prepare.sh and test.sh locally - looks like there's not too much to modify.

• use the sysroot built from source instead of rust-toolchain (not too hard, I can help)
• install hyperfine to the build/ directory instead of globally (very easy; we can do this only when RUSTC_BOOTSTRAP is set to avoid breaking any of your workflows)
• download your fork of gcc and set it in gcc_path. we might need to change the shell scripts to allow configuring where gcc_path is; or maybe just add it to .gitignore.

[antoyo]

@jyn514 That sounds good to me. The hyperfine stuff is not currently ran and should probably be skipped for in-tree testing.

Would that be simpler to use upstream GCC 12 instead of compiling GCC? That could be an option (of course, less tests would pass, but that would still be useful).

[jyn514]

Would that be simpler to use upstream GCC 12 instead of compiling GCC? That could be an option (of course, less tests would pass, but that would still be useful).

Yes, that would be super helpful to cut down on compile times :) Are there a known set of tests that fail, that we can manually exclude? Or can the failed tests change as you improve cg_gcc? If the latter than we might want to still build GCC from source so we have reliable tests.

[bjorn3]

Are there a known set of tests that fail, that we can manually exclude?

https://github.com/rust-lang/rustc_codegen_gcc/blob/master/failing-ui-tests12.txt is appended to the list of known failed tests in failing-ui-tests.txt on CI when testing with GCC 12.

[antoyo]

Or can the failed tests change as you improve cg_gcc?

In both cases, the failed tests can change, but the files pointed by bjorn3 will be updated accordingly.