bootstrap: Don't give a hard error on unknown paths if they're excluded

[jyn514]

The motivation for this is to allow x t compiler/* --exclude rustc_codegen_cranelift --exclude rustc_codegen_gcc
instead of the much more irritating

x t compiler/rustc compiler/rustc_apfloat compiler/rustc_arena compiler/rustc_ast compiler/rustc_ast_lowering compiler/rustc_ast_passes compiler/rustc_ast_pretty compiler/rustc_attr compiler/rustc_borrowck compiler/rustc_builtin_macros compiler/rustc_codegen_llvm compiler/rustc_codegen_ssa compiler/rustc_const_eval compiler/rustc_data_structures compiler/rustc_driver compiler/rustc_error_codes compiler/rustc_error_messages compiler/rustc_errors compiler/rustc_expand compiler/rustc_feature compiler/rustc_fs_util compiler/rustc_graphviz compiler/rustc_hir compiler/rustc_hir_pretty compiler/rustc_incremental compiler/rustc_index compiler/rustc_infer compiler/rustc_interface compiler/rustc_lexer compiler/rustc_lint compiler/rustc_lint_defs compiler/rustc_llvm compiler/rustc_log compiler/rustc_macros compiler/rustc_metadata compiler/rustc_middle compiler/rustc_mir_build compiler/rustc_mir_dataflow compiler/rustc_mir_transform compiler/rustc_monomorphize compiler/rustc_parse compiler/rustc_parse_format compiler/rustc_passes compiler/rustc_plugin_impl compiler/rustc_privacy compiler/rustc_query_impl compiler/rustc_query_system compiler/rustc_resolve compiler/rustc_save_analysis compiler/rustc_serialize compiler/rustc_session compiler/rustc_span compiler/rustc_symbol_mangling compiler/rustc_target compiler/rustc_traits compiler/rustc_trait_selection compiler/rustc_typeck compiler/rustc_type_ir compiler/rustc_ty_utils

@rustbot label +A-rustbuild +C-enhancement +A-contributor-roadblock

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

I could be convinced that a better way to do this is to allow x test compiler instead; but that seems confusing / ambiguous with running UI tests. The proper long-term fix is #95518, but I don't know how long that will take.

[Mark-Simulacrum]

I think part of me wants to say that the actual take-away here is "why are you trying to test all the compiler crates"?

IOW, it seems like if you've added unit tests to one crate, you probably want to run those specifically. If you've just made changes to the compiler, generally 99% of the time my recommendation is UI tests, not the very limited unit tests. Maybe in the long run that will change, though.

In the mean time, I think I'd prefer to avoid landing this and instead either pursue x.py test compiler or making testing gcc + cranelift something that's just a no-op for now (if we can't actually run those tests), so that passing compiler/* basically just works, presuming that's acceptable.

[jyn514]

I think part of me wants to say that the actual take-away here is "why are you trying to test all the compiler crates"?

Testing all the compiler crates is what caught #95994. But I could probably be convinced that's less important as long as we start testing those in CI.

In the mean time, I think I'd prefer to avoid landing this and instead either pursue x.py test compiler or making testing gcc + cranelift something that's just a no-op for now (if we can't actually run those tests), so that passing compiler/* basically just works, presuming that's acceptable.

I think I'll just live with manually specifying crates for now - it's not that hard to edit the command, and hopefully gcc+cranelift will work eventually.