sess: target modifiers under -T

[davidtwco]

cc rust-lang/compiler-team#980 (#t-compiler/major changes > group target modifier options under `-T` compiler-team#980)

This patch re-implements target modifiers so that they are grouped under -T instead of being regular flags.

The current implementation is quite complex, using lots of macro_rules!s to filter out the target modifier options from the rest of the codegen options, and then storing the original string values of the target modifiers in cross-crate metadata before re-parsing them again in the downstream crate. Some of this complexity is desirable - we don't want to store every option value in the cross-crate metadata because that would hurt compile times. This patch removes the current approach entirely and starts again, leveraging simplifications made possible by the -T design.

• The first commit (f283869) removes the existing target modifier infrastructure
• The second commit (1f5aba5) is a small renaming
• The next set of commits (3b95e08..208adfc) implements group target modifier options under -T compiler-team#980
  • A new TargetOptions struct is introduced that is parsed from -T and target modifier options are moved to it
  • TargetOptions is serialised in its entirety into cross-crate metadata, which is a lot simpler and isn't storing any more information than necessary
  • Local crate-only tracking of whether an option was actually set by the user is introduced, which is necessary to reproduce the previous diagnostics
  • Options can be set as TRACKED_UNSTABLE to require that -Zunstable-options be provided if they are used - all current target modifiers are unstable so this is used for all of them
  • Sanitizers are in both -T and -Z, with only address and leak being in -Z and everything else being in -T w/ -Zunstable-options
  • -Ttarget-cpu is required for targets with TargetOptions::requires_consistent_cpu, otherwise -Ctarget-cpu remains usable
  • -T itself is insta-stable, but all the options under are unstable, so it's effectively unstable
• The final set of commits (090db9c..c87f767) implements @Darksonn's suggestion from #t-compiler > Using -T for target modifiers and forwards compatibility @ 💬
  • tl;dr all -C options can also be used as -T options
    • We can remove these commits if we decide that we don't actually want to go this route, but I figured I'd try implement it
  • TargetOptions is removed again and target modifier options are now moved into CodegenOptions (they're still unstable thanks to the aforementioned TRACKED_UNSTABLE)
  • CodegenOptions is parsed from both -C and -T
    • -T takes precedence
  • Options can optionally be marked as TargetModifierFilter::Only (only -T, no -C) or TargetModifierFilter::Never (only -C, no -T)
  • -T option values are stored into a FxHashMap, these are stored into cross-crate metadata so we know which options were set as target modifiers in dependencies and we only store those that were set with -T
    • This hashmap is keyed by an CodegenOptionsKey enum that has a variant for each option
    • This hashmap's values are a TargetModifierValue type that contains variants for each distinct value type of the options we support as being target modifiers
      • Any option value types that TargetModifierValue doesn't support should be marked as never-target-modifiers, I haven't done that yet and rustc will ICE if you use them with -T
      • TargetModifierValue was introduced as an attempt to try and keep cross-crate metadata size down - avoiding Box<dyn Any> or storing strings for every option
  • -T is insta-stable for any of the currently stable -C options

To-do:

• -Zsanitizers-cfi-normalize-integers was previously only a target modifier for -Zsanitizers=kcfi, not -Zsanitizers=cfi, but it is now a target modifier for both
• Which version of the patch do we want?
• (for the interchangeable -C/-T version) Which options should never be usable as target modifiers? Options related to linking or file paths?

Opening this as a draft as there are clearly some questions to resolve above.

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking rustc_codegen_gcc v0.1.0 (/checkout/compiler/rustc_codegen_gcc)
error[E0609]: no field `regparm` on type `UnstableOptions`
   --> compiler/rustc_codegen_gcc/src/context.rs:535:55
    |
535 |             regparm: self.tcx.sess.opts.unstable_opts.regparm,
    |                                                       ^^^^^^^ unknown field
    |
    = note: available fields are: `allow_features`, `allow_partial_mitigations`, `always_encode_mir`, `annotate_moves`, `assert_incr_state` ... and 95 others

error[E0609]: no field `reg_struct_return` on type `UnstableOptions`
   --> compiler/rustc_codegen_gcc/src/context.rs:536:65
    |
536 |             reg_struct_return: self.tcx.sess.opts.unstable_opts.reg_struct_return,
    |                                                                 ^^^^^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `allow_features`, `allow_partial_mitigations`, `always_encode_mir`, `annotate_moves`, `assert_incr_state` ... and 95 others

For more information about this error, try `rustc --explain E0609`.
[RUSTC-TIMING] rustc_codegen_gcc test:false 1.204
error: could not compile `rustc_codegen_gcc` (lib) due to 2 previous errors
Bootstrap failed while executing `check`

[rust-bors]

☔ The latest upstream changes (presumably #160190) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.