Remove needs-asm-support directive in tests with explicit targets

[jchecahi]

The needs-asm-support directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via --target in their compile-flags, this directive is incorrect and unnecessary.

These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does.

Tests with explicit targets should rely on needs-llvm-components to ensure the appropriate backend is available, rather than checking host asm support.

[rustbot]

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[bjorn3]

Maybe instead of //@ compile-flags: --target ... we could have a //@ target directive that //@ needs-asm-support then checks? There are other directives that check properties of the target architecture that would be incorrect with //@ compile-flags: --target .... Some of which are genuinely necessary for other codegen backends, like //@ needs-unwind.

[workingjubilee]

I agree with bjorn re: the design. These directives likely hung around because they were non-cross tests before.

[jchecahi]

Thanks @bjorn3 and @workingjubilee for the feedback! I appreciate you both thinking about this. Let me explain my thinking on this change, and I'd appreciate your feedback on whether I'm understanding this correctly.

My understanding of the issue:

From what I can tell, the existing needs-asm-support directive's documentation was somewhat ambiguous - it said it "ignores if it is running on a target that doesn't have stable support for asm!". Based on the implementation and testing behavior, it appears to actually check the host architecture for asm support, not the target.

For these cross-compilation tests (which use --target to explicitly specify the target architecture), this seemed incorrect to me. For example, if we're running on a ppc64le host (which doesn't have stable asm support) and testing s390x assembly via --target s390x-unknown-linux-gnu, the test would be skipped even though:

• The ppc64le host can cross-compile to s390x fine
• s390x itself has stable asm support
• We're only validating the compiler's parsing/error messages, not executing code

This is, in fact, what is happens on Fedora ppc64le builds.

Why I went with just removing the directive:

Since these tests already use needs-llvm-components to ensure the appropriate backend is available, and they explicitly specify the target via --target in compile-flags, I thought removing needs-asm-support would be the right approach. The host's asm support shouldn't matter for cross-compilation tests that are checking target-specific assembly syntax and constraints.

I also updated the documentation for needs-asm-support in directives.md to clarify that it checks the host architecture, and to recommend using needs-llvm-components for cross-compilation tests instead.

Regarding the //@ target directive idea:

I can see how such directive could provide a more robust long-term solution, especially if there are other directives with similar host-vs-target confusion (like the needs-unwind example you mentioned). That makes a lot of sense.

I have to admit I'm not familiar enough with the compiletest infrastructure internals to do this confidently. I also don't have a lot of bandwidth right now for a larger refactoring. That said, if you both think this is an important improvement and something that would be reasonable for a less experienced contributor to tackle, I'd be willing to give it a try with some guidance.

Could you share your thoughts on:

• Whether implementing a //@ target directive would be a reasonable first step into compiletest for someone at my level?
• Any initial pointers on where in the codebase I should start looking (I assume somewhere in src/tools/compiletest/)?
• Whether there's existing similar directive handling I could use as a reference?

Alternatively, if this feels like it needs someone with deeper knowledge of the testing infrastructure, I completely understand - maybe this simpler fix could land as-is to address the immediate problem, and someone more experienced could implement the better long-term solution?

I'm open to either path and appreciate your guidance!

[cuviper]

we could have a //@ target directive that //@ needs-asm-support then checks?

I think there are some things that a target directive could improve, but directive or not, needs-asm-support is redundant in my view. For the in-tree compiler, the asm-support status of a given arch will always be the same, and presumably it is supported if someone bothered to write a specific target test (or else the test is not useful).

A target directive would be great to avoid manual needs-llvm-components though!

[jackh726]

I'm not super familiar with this area, but I'm inclined to land this, even if there is a better solution.

Adding a //@ target directive is useful - @jchecahi did you want to try to do a followup PR for that? If you need, I can dig in a bit to this and provide some followup mentorship (but maybe @bjorn3 or @workingjubilee would want to!)

@bjorn3 and @workingjubilee any concerns on merging this pending a better long-term solution?

[bors]

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