Update stdarch submodule (to before it switched to const generics)#83776
Update stdarch submodule (to before it switched to const generics)#83776bors merged 1 commit intorust-lang:masterfrom
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