Integrate stdarch tests for aarch64#1667
Conversation
Yeah, I think that would work better. Aside from currently being a shorter list, it also avoids mistakenly thinking a new failing test got added that can be disabled just fine rather than an existing test now failing. |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Now uses Switching from opt-out to opt-in will require some upstream work in The opt-in lists would likely be longer than the existing skip lists fwiw. |
| let mut lockfile_cmd = Command::new(&runner.target_compiler.cargo); | ||
| lockfile_cmd.arg("generate-lockfile"); | ||
| lockfile_cmd.arg("--manifest-path").arg(STDARCH_RUST_PROGRAMS.manifest_path(&runner.dirs)); | ||
| spawn_and_wait(lockfile_cmd); |
There was a problem hiding this comment.
Please instead put the lockfile in the patches directory of this repo and copy it over.
There was a problem hiding this comment.
This is the lockfile of the generated workspace, which I assumed would change too often. Maybe it's stable enough to manage via a patch.
Mentions generated packages like:
[[package]]
name = "mod_9"
version = "0.1.0"
dependencies = [
"cc",
"core_arch",
]There was a problem hiding this comment.
Right, they generate a mod per CPU core. So not sure a patch is feasible here.
|
☔ The latest upstream changes (possibly #1666) made this pull request unmergeable. Please resolve the merge conflicts. |
3 participants
Had a go at wiring up
stdarch. Runs thecore_archandintrinsic-testtest suites.Looked into x86 as well. It had more hard errors to resolve up front, so opted to stick with aarch64 for now.
The skip mechanism for these may be a little cumbersome to maintain.
Maybe making the tests opt-in rather than opt-out would be the better approach?