Fix#44833 (a very specific instance of a very broad bug).
In `check_if_path_is_moved(L)`, check nearest prefix of L with
MovePath, and suffixes of L with MovePaths.
Over the course of review, ariel pointed out a number of issues that
led to this version of the commit:
1. Looking solely at supporting prefixes does not suffice: it
overlooks checking if the path was ever actually initialized in the
first place. So you need to be willing to consider non-supporting
prefixes. Once you are looking at all prefixes, you *could* just
look at the local that forms the base of the projection, but to
handle partial initialization (which still needs to be formally
specified), this code instead looks at the nearest prefix of L that
has an associated MovePath (which, in the limit, will end up being
a local).
2. You also need to consider the suffixes of the given Lvalue, due to
how dataflow is representing partial moves of individual fields out
of struct values.
3. (There was originally a third search, but ariel pointed out that
the first and third could be folded into one.)
Also includes some drive-by refactorings to simplify some method
signatures and prefer `for _ in _` over `loop { }` (at least when it
comes semi-naturally).
Improve performance of spsc_queue and stream.
This PR makes two main changes:
1. It switches the `spsc_queue` node caching strategy from keeping a shared
counter of the number of nodes in the cache to keeping a consumer only counter
of the number of node eligible to be cached.
2. It separates the consumer and producers fields of `spsc_queue` and `stream` into
a producer cache line and consumer cache line.
Overall, it speeds up `mpsc` in `spsc` mode by 2-10x.
Variance is higher than I'd like (that 2-10x speedup is on one benchmark), I believe this is due to the drop check in `send` (`fn stream::Queue::send:107`). I think this check can be combined with the sleep detection code into a version which only uses 1 shared variable, and only one atomic access per `send`, but I haven't looked through the select implementation enough to be sure.
The code currently assumes a cache line size of 64 bytes. I added a CacheAligned newtype in `mpsc` which I expect to reuse for `shared`. It doesn't really belong there, it would probably be best put in `core::sync::atomic`, but putting it in `core` would involve making it public, which I thought would require an RFC.
Benchmark runner is [here](3eca46279c/shootout), benchmarks [here](3eca46279c/queue_bench/src/lib.rs (L170-L293)).
Fixes#44512.
1. Add -f flag to curl, so when the server returns 403 or 500 it will fail
immediately.
2. Moved the checksum part into the retry loop, assuming checksum failure
is due to broken download that can be fixed by downloading again.
This commit updates LLVM with a patch that's landed upstream to fix an assertion
that was tripping when ThinLTO was activated. Unfortunately I wasn't able to get
a reduced test case, but I've tested manually on the affected crates and the
assertion is indeed fixed.
Closes#45131
This informs LLVM that functions can't unwind, which while it should typically
have already been inferred when necessary or otherwise not impact codegen is
apparently needed on targets like ARM to avoid references to unnecessary
symbols.
Closes#44992
Refactor fmt::Display and fmt::Debug impls in ppaux
Also fixes#44887.
There was a problem that unnamed late-bound regions are *always* named `'r` while they are displayed using `std::fmt::Display`.
---
```rust
fn main() {
f(|_: (), _: ()| {});
}
fn f<F>(_: F) where F: Fn(&(), for<'r> fn(&'r ())) {}
```
Before (incorrectly shadows lifetime, `for<'r>` omitted for the second argument):
```
error[E0631]: type mismatch in closure arguments
--> test.rs:2:5
|
2 | f(|_: (), _: ()| {});
| ^ ----------------- found signature of `fn((), ()) -> _`
| |
| expected signature of `for<'r> fn(&'r (), fn(&'r ())) -> _`
|
= note: required by `f`
```
After:
```
error[E0631]: type mismatch in closure arguments
--> test.rs:2:5
|
2 | f(|_: (), _: ()| {});
| ^ ----------------- found signature of `fn((), ()) -> _`
| |
| expected signature of `for<'s> fn(&'s (), for<'r> fn(&'r ())) -> _`
|
= note: required by `f`
```
r? @nikomatsakis
ci: Fix installing the Android SDK
Apparently the https urls are broken due to some certificate validation
whatnots, and so far the least intrusive solution I've found is to just disable
that.
Apparently the https urls are broken due to some certificate validation
whatnots, and so far the least intrusive solution I've found is to just disable
that.
Fix path to x.py in bootstrap/configure.py script
We may see a help message in the end of the output of the ./configure script:
```
$ ./configure
configure: processing command line
configure:
configure: build.configure-args := []
configure:
configure: writing `config.toml` in current directory
configure:
configure: run `python ./src/bootstrap/x.py --help`
configure:
```
but the `x.py` script is actually in the rust root directory and
executing of such help string will give us error:
```
$ python ./src/bootstrap/x.py --help
python: can't open file './src/bootstrap/x.py': [Errno 2] No such file
or directory
```
This patch fixes path to the x.py script in the output of the ./configure
Update let-expressions.rs with DepNode labels
As a part of #44924, the PR has tests verified for the following dependency nodes for **let-expressions**
```
- MirValidated
- MirOptimized
- TypeCheckTables
- TypeOfItem
- GenericsOfItem
- PredicatesOfItem
- FnSignature
```
As we are more concerned with the function body, the following fingerprints do not change over compilation sessions.
```- TypeOfItem
- GenericsOfItem
- PredicatesOfItem
- FnSignature
```
r? @nikomatsakis
cc @michaelwoerister
P.S. Will add more tests as and when possible :)
Implement display_hint in gdb pretty printers
A few pretty-printers were returning a quoted string from their
to_string method. It's preferable in gdb to return a lazy string and to
let gdb handle the display by having a "display_hint" method that
returns "string" -- it lets gdb settings (like "set print ...") work, it
handles corrupted strings a bit better, and it passes the information
along to IDEs.
We may see a help message in the end of the output of the ./configure script:
$ ./configure
configure: processing command line
configure:
configure: build.configure-args := []
configure:
configure: writing `config.toml` in current directory
configure:
configure: run `python ./src/bootstrap/x.py --help`
configure:
but the x.py script is actually in the rust root directory and
executing of such help string will give us error:
$ python ./src/bootstrap/x.py --help
python: can't open file './src/bootstrap/x.py': [Errno 2] No such file
or directory
This patch fixes path to the x.py script in the output of the ./configure
It appears to be a simple oversight that `result::IntoIter<T>` doesn't
implement `Clone` (where `T: Clone`). We do already have `Clone` for
`result::Iter`, as well as the similar `option::IntoIter` and `Iter`.
incr.comp.: Move macro-export test case to src/test/incremental.
`compile-fail/incr_comp_with_macro_export.rs` was trying to role its own incremental compilation setup. This started to cause problems. There's no reason to not just make this a regular `src/test/incremental` test.
Fixes#45062.
Fix data-layout field in x86_64-unknown-linux-gnu.json test file
The current data-layout causes the following error:
> rustc: /checkout/src/llvm/lib/CodeGen/MachineFunction.cpp:151: void llvm::MachineFunction::init(): Assertion `Target.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"' failed.
The new value was generated according to [this comment by @japaric](https://github.com/rust-lang/rust/issues/31367#issuecomment-213595571).
Update comments referring to old check_method_self_type
I was browsing the code base, trying to figure out how #44874 could be implemented, and noticed some comments that were out of date and a bit misleading (`check_method_self_type` has since been renamed to `check_method_receiver`). Thought it would be an easy first contribution to Rust!
Ensure std::mem::Discriminant is Send + Sync
`PhantomData<*const T>` has the implication of Send / Syncness following
the *const T type, but the discriminant should always be Send and Sync.
Use `PhantomData<fn() -> T>` which has the same variance in T, but is Send + Sync
Band-aid fix to stop race conditions in llvm errors
This is a big hammer, but should be effective at completely removing a
few issues, including inconsistent error messages and segfaults when
LLVM workers race to report results
`LLVM_THREAD_LOCAL` has been present in LLVM since 8 months before 3.7
(the earliest supported LLVM version that Rust can use)
Maybe fixes#43402 (third time lucky?)
r? @alexcrichton
------
You can see that in 5f578dfad0/src/librustc_trans/back/write.rs (L75-L100) there's a small window where the static global error message (made thread local in this PR) could be altered by another thread.
Note that we can't use `thread_local` because gcc 4.7 (permitted according to the readme) does not support it.
Maybe ideally all the functions should be modified to not use a global, but this PR makes things deterministic at least. My only hesitation is whether errors are checked in different threads to where they occur, but I figure that's probably unlikely (and is less bad than racing code).
As an aside, segfault evidence before this patch when I was doing some debugging:
```
$ while grep 'No such file or directory' log2; do RUST_LOG=debug ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" y.rs >log2 2>&1; done
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
Segmentation fault (core dumped)
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
```
This is a big hammer, but should be effective at completely removing a
few issues, including inconsistent error messages and segfaults when
LLVM workers race to report results
LLVM_THREAD_LOCAL has been present in LLVM since 8 months before 3.7
(the earliest supported LLVM version that Rust can use)
Maybe fixes#43402 (third time lucky?)
