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?)
Improve raw Box conversions
This PR has two goals:
- Reduce use of `mem::transmute` in `Box` conversions
I understand that `mem::transmute`-ing non `#[repr(C)]` types is implementation-defined behavior. This may not matter within the reference implementation of Rust, but I believe it's important to remain consistent. For example, I noticed that `str::from_utf8_unchecked` went from using `mem::transmute` to using pointer casts.
- Make `Box` pointer conversions more straightforward regarding `Unique`
Some targets, like msp430 and nvptx, don't work with multiple codegen units
right now for bugs or fundamental reasons. To expose this allow targets to
express a default.
Closes#45000
Don't panic in the coordinator thread, bubble up the failure
Fixes#43402 (take 2)
Followup to #45019, this makes the coordinator thread not panic on worker failures since they can be reported reasonably back in the main thread.
The output also now has no evidence of backtraces at all, unlike the previous PR:
```
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" x.rs
error: could not write output to : No such file or directory
error: aborting due to previous error
```
r? @alexcrichton
Clarify RAM usage during build in README
The sentence wasn't immediately clear if it meant RAM or disk space before reading the next sentence.
I think this helps clarify it.
Update grammar to parse current rust syntax
Mainly addressing #32723. This PR updates the bison grammar so that it can parse the current rust syntax, except for feature-gated syntax additions. It has been tested with all the tests in run-pass.
The grammar in this repo doesn't have build logic anymore, but you can test it out in https://github.com/bleibig/rust-grammar, which has all of what's in this PR. If you are interested in having build logic and grammar tests again, I can look into implementing that as well.
I'm aware that things are somewhat undecided as to what an official rust grammar should be from the discussion in #30942. With this PR we can go back to having an up-to-date flex/bison based grammar, but the rustypop grammar looks interesting as well.
Use identity operator `is` when comparing to None
This is very minor, but idiomatic Python code uses `is` for comparisons to `None`. This is because semantically we want to compare to the "identity" of `None`, not its value.
See [PEP8 for details](https://www.python.org/dev/peps/pep-0008/#programming-recommendations).
Fix variable name reference
As best I can tell, this was a typo due to how similar it looks to the function above it. PyCharm found this as a unbound local variable.
Fix raising a bare str as an exception in configure.py
Raising a bare `str` has been [deprecated since Python 2.5](https://docs.python.org/2/whatsnew/2.5.html#pep-352-exceptions-as-new-style-classes).
On Python 2.7 it produces the following error:
```
TypeError: exceptions must be old-style classes or derived from BaseException, not str
```
For maximum compatibility with Python 2.7 and 3.x, we wrap the error message in `RuntimeError` which derives from `Exception`.
rustc: Don't inline in CGUs at -O0
This commit tweaks the behavior of inlining functions into multiple codegen
units when rustc is compiling in debug mode. Today rustc will unconditionally
treat `#[inline]` functions by translating them into all codegen units that
they're needed within, marking the linkage as `internal`. This commit changes
the behavior so that in debug mode (compiling at `-O0`) rustc will instead only
translate `#[inline]` functions into *one* codegen unit, forcing all other
codegen units to reference this one copy.
The goal here is to improve debug compile times by reducing the amount of
translation that happens on behalf of multiple codegen units. It was discovered
in #44941 that increasing the number of codegen units had the adverse side
effect of increasing the overal work done by the compiler, and the suspicion
here was that the compiler was inlining, translating, and codegen'ing more
functions with more codegen units (for example `String` would be basically
inlined into all codegen units if used). The strategy in this commit should
reduce the cost of `#[inline]` functions to being equivalent to one codegen
unit, which is only translating and codegen'ing inline functions once.
Collected [data] shows that this does indeed improve the situation from [before]
as the overall cpu-clock time increases at a much slower rate and when pinned to
one core rustc does not consume significantly more wall clock time than with one
codegen unit.
One caveat of this commit is that the symbol names for inlined functions that
are only translated once needed some slight tweaking. These inline functions
could be translated into multiple crates and we need to make sure the symbols
don't collideA so the crate name/disambiguator is mixed in to the symbol name
hash in these situations.
[data]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334880911
[before]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334583384
Add pretty printer files into test execution time-stamping
Move find_rust_src_path() as a method for Config
Move find_rust_src_path() as a method for Config
Call find_rust_src_path() from Config
Move find_rust_src_path() from common.rs to header.rs
Add pretty printer files as relevant files to get up_to_date information
Remove dead code
Add two pretty printer files to keep a close watch on
Move find_rust_src_path() as a method for Config
Move find_rust_src_path() as a method for Config
Call find_rust_src_path() from Config
Move find_rust_src_path() from common.rs to header.rs
Remove dead code
Add two pretty printer files to keep a close watch on
Remove support for the PNaCl target (le32-unknown-nacl)
This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format.
There are two reasons for the removal:
* Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend!
* Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust.
Fixes#42420
rustc: Don't create empty codegen units
This'll end up just creating a bunch of object files that otherwise wouldn't
exist, so skip that extra work if possible.
rustc_trans: do not set NoCapture for anonymous lifetime &T arguments.
This was both unsound (due to lifetime elision & unsafe code) and dead code (we erase lifetimes).
r? @nikomatsakis
