It's technically correct in that I believe those would work if they're included in the directives allow list (lol).

If every new target has to be added to some allow list, that will never be up-to-date. compiletest should accept all targets supported by rustc then.

The intention in the long term is to not have to rely on any allow list, it obviously doesn't scale

Also, I assume then this is similar for architectures etc? Would be good to document that so that one knows what to do when an architecture is not recognized.

The intention in the long term is to not have to rely on any allow list, it obviously doesn't scale

compiletest already queries rustc for various things, right? Can't it query the target list?

There's two parts to this:

1. compiletest already does the target list query. Those targets are already valid ignore-$targets cf

   rust/src/tools/compiletest/src/header/cfg.rs

   Lines 103 to 107 in c6c1796

   	condition! {
   	name: &config.target,
   	allowed_names: &target_cfgs.all_targets,
   	message: "when the target is {name}"
   	}

   .
2. But they just get denied by the allow-list (which is a short-term bandaid to detect unknown directives) that I want to get rid of soon

Also, I assume then this is similar for architectures etc? Would be good to document that so that one knows what to do when an architecture is not recognized.

Yes, it's the same for archs. The valid archs are already computed based on all the builtion-targets combined + some extra archs

I'll send a PR to document the current impl limitation in rustc-dev-guide.

If you still need those //@ ignore-$target_tuple for your PR, then you should only need to add them to

rust-lang/rustc-dev-guide#2319

Why can't they be added to the allowlist automatically? We should be rejecting unknown directives, that is not a bandaid. But targets on the builtin target list are not "unknown".

Because I haven't gotten around to fixing that bit yet :)

Really, if none of the directive parsers matched a directive-like line then it should just fail (but it doesn't do that yet).

Exactly. The separate allowlist is an artifact leftover from when I was migrating compiletest directives from // to //@ (because the plain comment form had too much false-positive potential that made it too noisy to do proper unknown directive detection) to make sure I don't silently drop/miss directives, which has persisted longer than I wanted to, because I keep getting distracted by various things :D