Remove the #[no_sanitize] attribute in favor of #[sanitize(xyz = "on|off")]

[1c3t3a]

This came up during the sanitizer stabilization (#123617). Instead of a #[no_sanitize(xyz)] attribute, we would like to have a #[sanitize(xyz = "on|off")] attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was discussed on Zulip).

The new attribute also works on modules, traits and impl items and thus enables usage as the following:

#[sanitize(address = "off")]
mod foo {
    fn unsanitized(..) {}

    #[sanitize(address = "on")]
    fn sanitized(..) {}
}

trait MyTrait {
  #[sanitize(address = "off")]
  fn unsanitized_default(..) {}
}

#[sanitize(thread = "off")]
impl MyTrait for () {
    ...
}

r? @rcvalle

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

Some changes occurred in src/doc/unstable-book/src/language-features/no-sanitize.md

cc @rust-lang/project-exploit-mitigations, @rcvalle

Some changes occurred in tests/codegen/sanitizer

cc @rcvalle

Some changes occurred in tests/ui/sanitizer

cc @rcvalle

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

[rcvalle]

Thank you very much for your time and work on this, @1c3t3a! Much appreciated.

[rcvalle]

cc @Darksonn @wesleywiser @traviscross

[Darksonn]

It doesn't matter for me, but should we make this change gradually by supporting both for some time?

[1c3t3a]

It doesn't matter for me, but should we make this change gradually by supporting both for some time?

That's possible for sure, I put stuff into different commits for that reason and I can just drop the middle commit to have both exist in parallel.

What's the reason for having both at the same time? An easier migration period?

[traviscross]

We generally do not make such efforts to migrate usage of nightly features without a specific known good reason to do so. (Let us know of course if there is one, e.g. if this affects RfL in some way.)