-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update stdarch submodule (to before it switched to const generics) #83776
Conversation
|
This comment has been minimized.
This comment has been minimized.
f9e8abd
to
dccfc81
Compare
This comment has been minimized.
This comment has been minimized.
I think you'll need to cherry-pick rust-lang/stdarch#1089 which was added after the port to If you create a branch with that cherry pick then I can push it to rust-lang/stdarch so that you can use it for the submodule. |
Thanks! https://github.com/jyn514/stdarch/tree/doc-include-fixed has the cherry-picked fix. |
dccfc81
to
bbddfb4
Compare
This comment has been minimized.
This comment has been minimized.
It looks like this error is also present in the other PR: #83278 (comment). I think this may actually be a breaking change and libstd needs to re-export the macro in the crate root? I'll try that. |
bbddfb4
to
56c9326
Compare
Ok, I think that should have worked. |
This comment has been minimized.
This comment has been minimized.
56c9326
to
d0fd13f
Compare
Oh, I guess all the macros need the same treatment. @Amanieu is there an easy way to see all macros that are declared by stdarch? Is searching for |
d0fd13f
to
70098c6
Compare
This comment has been minimized.
This comment has been minimized.
Apparently there are two different tracking issues for simd (??) #48556 #27731 https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Why.20are.20there.20two.20tracking.20issues.20for.20SIMD.3F |
70098c6
to
f297a40
Compare
I'm not sure what's up with the two separate tracking issues, but this can be resolved separately. @bors r+ rollup=never |
📌 Commit f297a4072cba08bab1f3fcf589247291fff79add has been approved by |
⌛ Testing commit f297a4072cba08bab1f3fcf589247291fff79add with merge 59e207563090269860362bc18eea72adbe563a7e... |
This comment has been minimized.
This comment has been minimized.
@bors retry |
So fixing the error is easy enough, but I'm having trouble replicating it to make sure the fix is right. It looks like |
The |
It's part of the |
… r=Mark-Simulacrum Fix racing file access in tidy That should fix the failure in rust-lang#83776 (comment) The file is only created for a brief moment during the bins checks in the source directories while other checks may also be visiting the same directory. By skipping it we avoid file not found errors.
I've updated the rustc-2021-04-02 branch on stdarch with rust-lang/stdarch#1108. |
This also includes a cherry-pick of rust-lang/stdarch@ec14619 and rust-lang/stdarch#1108 to fix a build failure. It also adds a re-export of various macros to the crate root of libstd - previously they would show up automatically because std_detect was defined in the same crate.
f297a40
to
1b0b7e9
Compare
@bors r+ |
📌 Commit 1b0b7e9 has been approved by |
☀️ Test successful - checks-actions |
This should also fix some arch-specific detect bugs |
FWIW, this was a 1.4-1.5% memory usage regression on check, debug, and opt builds. I don't know that we necessarily want to do anything here - this may be entirely mitigated by the const generics rewrites. But thought I'd flag it. |
Could this be because we are importing |
Fix build-std updating the index on every build. rust-lang/rust#83776 has caused a problem where build-std will update the index on every build. That PR added `std_detect` from the `stdarch` submodule as a path dependency of `std`. However, since `stdarch` has a workspace of its own, an exclusion had to be added to `Cargo.toml` so that it does not treat `std_detect` as a workspace member (because nested workspaces are not supported). The problem is that the std `Cargo.lock` file is built thinking that `std_detect` is *not* a workspace member. This means that its dev-dependencies are not included. However, when cargo resolves the std workspace, it doesn't know that `std_detect` should be excluded, so it considers it a workspace member (because it is a path dependency). This means that it expects the dev-dependencies to be in Cargo.lock. Because they are missing, it ends up poisoning the registry and triggering an update: > poisoning registry `https://github.com/rust-lang/crates.io-index` because std_detect v0.1.5 (/Users/eric/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/stdarch/crates/std_detect) looks like it changed auxv The solution here is to skip dev-dependencies if they are not actively being resolved, even if the package is a workspace member. This has happened before (#8962), so I have updated the test to check for it. There are some alternative solutions I considered: * Add support for nested workspaces. 😄 * Use a symlink to `std_detect` in the `rust-lang/rust` repository so that it appears to cargo as-if it is "outside" of the stdarch workspace, and thus can be treated like a normal workspace member (and remove the "exclude"). That seems a little hacky. Fixes #9390
#83278 (comment): This unblocks #82539.
Major changes:
I double-checked and the first use of const generics looks like rust-lang/stdarch@8d50178, which isn't included in this PR.
r? @Amanieu