Remove wrong advice about spin locks from `spin_loop_hint` docs
Using a pure spin lock for a critical section in a preemptable thread
is always wrong, however short the critical section may be. The thread
might be preempted, which will cause all other threads to hammer
busily at the core for the whole quant. Moreover, if threads have
different priorities, this might lead to a priority inversion problem
and a deadlock. More generally, a spinlock is not more efficient than
a well-written mutex, which typically does several spin iterations at
the start anyway.
The advise about UP vs SMP is also irrelevant in the context of
preemptive threads.
See also accompanying piece: https://matklad.github.io/2020/01/02/spinlocs-considered-harmful.html
And another, independent piece: https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is
EDIT: obligatory disclosure that I am not an expert in these things, and might be terribly wrong :)
Move `is_min_const_fn` query to librustc_mir.
The only two uses of the associated methods are in `librustc_mir` and
`librustdoc`. Please tell me if there is a better choice.
cc #65031
Try statx for all linux-gnu target.
After https://github.com/rust-lang/libc/pull/1577, which is contained in `libc` 0.2.66, provides `SYS_statx` for all Linux platform, so we can try to use `statx` for ~all Linux target~ all linux-gnu targets.
Unfortunately, `struct statx` and `fn statx` is not a part of public interface of musl (currently), ~we still need to invoke it through `syscall`~ we does **not** support statx for musl or other libc impls currently.
Previous PR: #65094
cc @alexcrichton
More reductions in error handling diversity
In this follow up to https://github.com/rust-lang/rust/pull/67744, we:
- Remove all fatal / error / warning macros in `syntax` except for `struct_span_err`, which is moved to `rustc_errors`.
- Lintify some hard-coded warnings which used warning macros.
- Defatalize some errors.
In general, the goal here is to make it painful to use fatal or unstructured errors and so we hopefully won't see many of these creep in.
Fixes https://github.com/rust-lang/rust/issues/67933.
Clear out target directory if compiler has changed
Previously, we relied fully on Cargo to detect that the compiler had changed and
it needed to rebuild the standard library (or later "components"). This used to
not quite be the case prior to moving to LLVM be a separate cargo invocation;
subsequent compiles would recompile std and friends if LLVM had changed
(#67077 is the PR that changes things here).
This PR moves us to clearing out libstd when it is being compiled if the rustc
we're using has changed. We fairly harshly limit the cases in which we do this
(e.g., ignoring dry run mode, and so forth, as well as rustdoc invocations).
This is primarily because when we're not using the compiler directly, so
clearing out in other cases is likely to lead to bugs, particularly as our
deletion scheme is pretty blunt today (basically removing more than is needed,
i.e., not just the rustc artifacts).
In practice, this targeted fix does fix the known bug, though it may not fully
resolve the problem here. It's also not clear that there is a full fix hiding
here that doesn't involve a more major change (like -Zbinary-dep-depinfo was).
As a drive-by fix, don't delete the compiler before calling Build::copy, as that
also deletes the compiler.
GitHub Actions: preparations, part 2
This PR adds the second batch of commits in preparation for GitHub Actions:
* Removed hardcoded Azure Pipelines variables from `publish_toolstate.sh`
* Fixed a bug in `shared.sh`'s GitHub Actions support
* Fixed binutils missing from MSYS2 on Windows 2019 (GitHub Actions-specific)
* Fixed wrong sysroot in macOS 10.15 onwards (GitHub Actions-specific)
This PR does **not** yet add any builders on GitHub Actions.
r? @alexcrichton
Simplify Clone for Box<[T]>
The bespoke `BoxBuilder` was basically a very simple `Vec`. Instead,
let's clone to a real `Vec`, with all of its specialization for the
task, then convert back to `Box<[T]>`.
ci: remove 32-bit Apple targets
This PR drops the `i686-apple` and `dist-i686-apple` CI builders, as well as removing the `armv7-apple-ios`, `armv7s-apple-ios` and `i386-apple-ios` targets from the `x86_64-apple` CI builder.
The change was approved in [RFC 2837](https://github.com/rust-lang/rfcs/pull/2837), and it should land in Rust 1.42 stable (so this cycle).
r? @alexcrichton
Update cargo
9 commits in 86134e7666a088682f20b76278c3ee096a315218..6e1ca924a67dd1ac89c33f294ef26b5c43b89168
2019-12-23 16:08:07 +0000 to 2020-01-06 19:11:37 +0000
- Fix dynamic linking for Windows UWP MSVC targets (rust-lang/cargo#7758)
- Fix CARGO_TARGET_triple_LINKER environment variable. (rust-lang/cargo#7763)
- Remove metadata dep_kinds duplicates. (rust-lang/cargo#7756)
- Check for a source defined multiple times. (rust-lang/cargo#7751)
- Fix typo. (rust-lang/cargo#7735)
- Fix config env vars that are prefix of another with underscore. (rust-lang/cargo#7748)
- Add test for `cargo pkgid` (rust-lang/cargo#7741)
- Add a note to the error message for using --feature / --no-default-features in a virtual workspace (rust-lang/cargo#7742)
- Fix debug message. (rust-lang/cargo#7749)
Fix ICE in const pretty printing and resolve FIXME
Consts now have a `fmt::Display` impl, so we can just use that to pretty-print.
This resolves an ICE in https://github.com/rust-lang/rust/issues/61936, though it hits more ICEs afterwards. I couldn't find a test case that was resolved by this that didn't hit errors later on.
Handle multiple error fix suggestions carefuly
The existing code seems to assume that substitutions spans are disjoint,
which is not always the case.
In the example:
pub trait AAAA {}
pub trait B {}
pub trait C {}
pub type T<P: AAAA + B + C> = P;
, we get three substituions starting from ':' and ending respectively at
the end of each trait token.
With the former offset calculation, this would cause `underline_start` to
eventually become negative before being converted to `usize`...
The new version may report erroneous results for non perfectly overlapping
substitutions but I don't know if such examples exist. Alternatively, we
could detect these cases and trim out overlapping substitutions.
Fixes#67690
Add an unstable conversion from thread ID to u64
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).
It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
I will file a tracking issue as soon as this is loosely approved.
Yuki Okushi
bors
Camille GILLOT
oxalica
Mazdak Farrokhzad
Ralf Jung
Eric Huss
