Fix rustbuild per-target musl root
In #36292, support was added to target musl libc for ARM targets using rustbuild. Specifically, that change allowed the addition of per-target `musl-root` options in the rustbuild `config.toml` so that multiple targets depending on musl could be built. However, that implementation contained a couple of omissions: the `musl-root` option was added to the config, but was never added to the TOML parsing, and therefore was not actually being loaded from `config.toml`. This PR rectifies that.
Using these changes and a heavily modified version of the buildbot Docker container, I have been able to build rust targeting `armv7-unknown-linux-musleabihf` and have successfully run the binaries on a Raspberry Pi 3. I'm also planning to test `arm-unknown-linux-musleabi` and `arm-unknown-linux-musleabihf` systems, but have no reason to believe that this change would not simply work on those targets.
Add testcase for issue-32948
issue-32948 is similar to issue-32554.
issue-32948 : Symbol names for monomorphized trait impls are not stable across crates
issue-32554 : Symbol names for generics are not stable across crates
so, I append issue-32948's testcase to issue-32554's testcase.
thanks!
Restore `DISCONNECTED` state in `oneshot::Packet::send`
Closes#32114
I'm not sure if this is the best approach, but the current action of swapping `DISCONNECTED` with `DATA` seems wrong. Additionally, it is strange that the `send` method (and others in the `oneshot` module) takes `&mut self` despite performing atomic operations, as this requires extra discipline to avoid data races and lets us use methods like `AtomicUsize::get_mut` instead of methods that require a memory ordering.
stop having identity casts be lexprs
that made no sense (see test), and was incompatible with borrowck.
Fixes#36936.
beta-nominated since (bad) regression.
r? @eddyb
The previous panic message delivered when a musl target was specified
but musl-root was not specified incorrectly instructed the user to add
the musl-root key to the "build" section of config.toml. The key
actually needs to be added to the "rust" section.
In #36292, support was added to target musl libc for ARM targets using
rustbuild. Specifically, that change allowed the addition of per-target
"musl-root" options in the rustbuild config.toml so that multiple
targets depending on musl could be built. However, that implementation
contained a couple of omissions: the musl-root option was added to the
config, but was never added to the TOML parsing, and therefore was not
actually being loaded from config.toml. This commit rectifies that and
allows successful building of musl-based ARM targets.
Refactoring/bugfixing around definitions for struct/variant constructors
d917c364ad separates definitions for struct/variant constructors living in value namespace from struct/variant type definitions.
adfb37827b fixes cross-crate resolution of reexports reexporting half-items, like struct constructors without struct type or types without constructor. Such reexports can appear due to glob shadowing.
Resolution now is not affected by the order in which items and reexports are decoded from metadata (cc https://github.com/rust-lang/rust/issues/31337#issuecomment-183996263). `try_define` is not used during building reduced graph anymore.
500 lines of this PR are tests for this exotic situation, the remaining line diff count is actually negative! :)
c695d0c875 (and partially aabf132de0) moves most of pattern resolution checks from typeck to resolve (except those checking for associated items), uses the same wording for pattern resolution error messages from both typeck and resolve and makes the messages more precise.
11e3524e5a fixes seemingly incorrectly set `NON_ZERO_SIZED` attributes for struct/variant ctors in const eval.
4586fea253 eliminates `ty::VariantKind` in favor of `def::CtorKind`. The logic is that variant kinds are irrelevant for types, they make sense only when we deal with constructor functions/constants. Despite that `VariantDefData` still keeps a copy of `CtorKind`, but it's used only for various kinds of pretty-printing (and for storing in metadata).
aabf132de0 is mostly a cleanup of various impossible or improperly used definitions, and other small definition cleanups.
cc @jseyfried
r? @eddyb
rustc: Try again to disable NEON on armv7 linux
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
Closes#36913
