thread::unpark: Avoid notifying with mutex locked.
This means when the other thread wakes it can continue right away
instead of having to wait for the mutex.
Also add some comments explaining why the mutex needs to be locked in
the first place.
This is a follow up to https://github.com/rust-lang/rust/pull/54174
I did some tests with relacy [here](https://gist.github.com/parched/b7fb88c97755a81e5cb9f9048a15f7fb) (This PR is InnerV2). If anyone can think of some other test case worth adding let me know.
r? @RalfJung
ci: Move global credentials to web configuration
This commit moves a number of our encrypted credentials stored in
configuration files in this repository to env vars on the web UI. This
will hopefully make it easier to rotate credentials in the future as
well as quickly change them if the need arises. (quicker than landing a
PR that is).
This also updates the travis deployment process to always use the `aws`
command line tool which we're already installing on Linux and should
enable us to avoid all `dpl` gem issues as well as have greater control
over what's going where.
Fix DWARF generation for enums
The DWARF generated for Rust enums was always somewhat unusual.
Rather than using DWARF constructs directly, it would emit magic field
names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR". Since
PR #45225, though, even this has not worked -- the ad hoc scheme was
not updated to handle the wider variety of niche-filling layout
optimizations now available.
This patch changes the generated DWARF to use the standard tags meant
for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part.
The patch to implement this went in to LLVM 7. In order to work with
older versions of LLVM, and because LLVM doesn't do anything here for
PDB, the existing code is kept as a fallback mode.
Support for this DWARF is in the Rust lldb and in gdb 8.2.
Closes#32920Closes#32924Closes#52762Closes#53153
This means when the other thread wakes it can continue right away
instead of having to wait for the mutex.
Also add some comments explaining why the mutex needs to be locked in
the first place.
Update compiler-builtins submodule
This commit updates our `compiler-builtins` submodule which brings in at
least a few improvements for intrinsics on wasm32
The enum debuginfo patch includes a legacy mode that is used when
building against LLVM 5 and LLVM 6. The main enum debuginfo tests
have been updated to rely on the new approach and a new-enough gdb.
This patch makes a copy of these tests so that the fallback mode will
continue to be tested.
Note that nil-enum.rs is not copied; it seemed not to provide enough
value to bother.
A new header directive is added, "ignore-llvm-version". I will send a
patch to update the rustc documentation once this lands.
Bug #52452 notes some debuginfo test regressions when moving to gdb
8.1. This series will also cause versions of gdb before 8.2 to fail
when a recent LLVM is used -- DW_TAG_variant_part support was not
added until 8.2.
This patch updates one of the builders to a later version of Ubuntu,
which comes with gdb 8.2. It updates the relevant tests to require
both a new-enough LLVM and a new-enough gdb; the subsequent patch
arranges to continue testing the fallback mode.
The "gdbg" results are removed from these tests because the tests now
require a rust-enabled gdb.
If you read closely, you'll see that some of the lldb results in this
patch still look a bit strange. This will be addressed in a
subsequent patch; I believe the fix is to disable the Python
pretty-printers when lldb is rust-enabled.
The DWARF generated for Rust enums was always somewhat unusual.
Rather than using DWARF constructs directly, it would emit magic field
names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR". Since
PR #45225, though, even this has not worked -- the ad hoc scheme was
not updated to handle the wider variety of niche-filling layout
optimizations now available.
This patch changes the generated DWARF to use the standard tags meant
for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part.
The patch to implement this went in to LLVM 7. In order to work with
older versions of LLVM, and because LLVM doesn't do anything here for
PDB, the existing code is kept as a fallback mode.
Support for this DWARF is in the Rust lldb and in gdb 8.2.
Closes#32920Closes#32924Closes#52762Closes#53153
Rollup of 12 pull requests
Successful merges:
- #54885 (Don't lint 'unused_parens` on `if (break _) { .. }`)
- #55205 (Improve a few cases of collecting to an FxHash(Map/Set))
- #55450 (msp430: remove the whole Atomic* API)
- #55459 (Add UI test for #49296)
- #55472 (Use opt.take() instead of mem::replace(opt, None))
- #55473 (Take advantage of impl Iterator in (transitive/elaborate)_bounds)
- #55474 (Fix validation false positive)
- #55476 (Change a flat_map with 0/1-element vecs to a filter_map)
- #55487 (Adjust Ids of path segments in visibility modifiers)
- #55493 (Doc fixes)
- #55494 (borrowck=migrate must look at parents of closures)
- #55496 (Update clippy)
Failed merges:
r? @ghost
borrowck=migrate must look at parents of closures
This fixes the NLL migration mode (which is the default with edition=2018) to inspect all parents of a closure in addition to the closure itself when looking to see if AST-borrowck issues an error for the given code.
This should be a candidate for beta backport.
Fix#55492
Take advantage of impl Iterator in (transitive/elaborate)_bounds
Other than for `debug!`ging purposes, `bounds` are only iterated over, so they don't need to be collected into vectors.
msp430: remove the whole Atomic* API
PR #51953 enabled the Atomic*.{load,store} API on MSP430. Unfortunately,
the LLVM backend doesn't currently support those atomic operations, so this
commit removes the API and leaves instructions on how and when to enable it
in the future.
the second fixes compiling liballoc for msp430
closes#54511
r? @alexcrichton
cc @chernomor @awygle @cr1901 @pftbest
I removed the original file that more completely captured the original
crate's tests, as its source crate
(https://crates.io/crates/collection) is licensed under GPL3, and I
suspect that license is not loose enough for me to put into our repo
under our MIT/Apache licensing.
(Would it be an option to attach the GPL3 licesne to just the one
test? Probably. But do I want to bother with it that that point?
Nope!)
