bors [Fri, 22 May 2020 11:24:24 +0000 (11:24 +0000)]
Auto merge of #72460 - RalfJung:rollup-28fs06y, r=RalfJung
Rollup of 4 pull requests
Successful merges:
- #71610 (InvalidUndefBytes: Track size of undef region used)
- #72161 (Replace fcntl-based file lock with flock)
- #72306 (Break tokens before checking if they are 'probably equal')
- #72325 (Always generated object code for `#![no_builtins]`)
Ralf Jung [Fri, 22 May 2020 09:32:25 +0000 (11:32 +0200)]
Rollup merge of #72325 - alexcrichton:ignore-linker-plugin-lto, r=nnethercote
Always generated object code for `#![no_builtins]`
This commit updates the code generation for `#![no_builtins]` to always
produce object files instead of conditionally respecting
`-Clinker-plugin-lto` and sometimes producing bitcode. This is intended
to address rust-lang/cargo#8239.
The issue at hand here is that Cargo has tried to get "smarter" about
codegen in whole crate graph scenarios. When LTO is enabled it attempts
to avoid codegen on as many crates as possible, opting to pass
`-Clinker-plugin-lto` where it can to only generate bitcode. When this
is combined with `-Zbuild-std`, however, it means that
`compiler-builtins` only generates LLVM bitcode instead of object files.
Rustc's own LTO passes then explicitly skip `compiler-builtins` (because
it wouldn't work anyway) which means that LLVM bitcode gets sent to the
linker, which chokes most of the time.
The fix in this PR is to not actually respect `-Clinker-plugin-lto` for
`#![no_builtins]` crates. These crates, even if slurped up by the linker
rather than rustc, will not work with LTO. They define symbols which are
only referenced as part of codegen, so LTO's aggressive internalization
would trivially remove the symbols only to have the linker realize later
that the symbol is undefined. Since pure-bitcode never makes sense for
these libraries, the `-Clinker-plugin-lto` flag is silently ignored.
Ralf Jung [Fri, 22 May 2020 09:32:23 +0000 (11:32 +0200)]
Rollup merge of #72306 - Aaron1011:feature/turbo-spacing, r=petrochenkov
Break tokens before checking if they are 'probably equal'
Fixes #68489
Fixes #70987
When checking two `TokenStreams` to see if they are 'probably equal',
we ignore the `IsJoint` information associated with each `TokenTree`.
However, the `IsJoint` information determines whether adjacent tokens
will be 'glued' (if possible) when construction the `TokenStream` - e.g.
`[Gt Gt]` can be 'glued' to `BinOp(Shr)`.
Since we are ignoring the `IsJoint` information, 'glued' and 'unglued'
tokens are equivalent for determining if two `TokenStreams` are
'probably equal'. Therefore, we need to 'unglue' all tokens in the
stream to avoid false negatives (which cause us to throw out the cached
tokens, losing span information).
Ralf Jung [Fri, 22 May 2020 09:32:21 +0000 (11:32 +0200)]
Rollup merge of #72161 - nbdd0121:master, r=cuviper
Replace fcntl-based file lock with flock
WSL1 does not support `fcntl`-based lock and will always report success,
therefore creating a race condition when multiple rustc processes are
modifying shared data such as `search-index.js`. WSL1 does however
support `flock`.
`flock` is supported by all unix-like platforms. The only caveat is that
Linux 2.6.11 or earlier does not support `flock` on NFS mounts, but as
the minimum supported Linux version is 2.6.18, it is not an issue.
Ralf Jung [Fri, 22 May 2020 09:32:18 +0000 (11:32 +0200)]
Rollup merge of #71610 - divergentdave:InvalidUndefBytes-range, r=RalfJung
InvalidUndefBytes: Track size of undef region used
This PR adds a size to `UndefinedBehaviorInfo::InvalidUndefBytes`, to keep track of how many undefined bytes in a row were accessed, and changes a few methods to pass this information through. This additional information will eventually be used in Miri to improve diagnostics for this UB error. See also rust-lang/miri#1354 for prior discussion.
I expect Miri will break the next time its submodule is updated, due to this change to the `InvalidUndefBytes`. (The current commit for src/tools/miri predates rust-lang/miri#1354, and thus does not try to destructure the `InvalidUndefBytes` variant) I have a corresponding change prepared for that repository.
bors [Fri, 22 May 2020 08:04:45 +0000 (08:04 +0000)]
Auto merge of #72458 - RalfJung:rollup-g1w1vws, r=RalfJung
Rollup of 6 pull requests
Successful merges:
- #71607 (clarify interaction of pin drop guarantee and panics)
- #72125 (remove broken link)
- #72133 (Add target thumbv7a-uwp-windows-msvc)
- #72304 (rustc_target: Avoid an inappropriate use of `post_link_objects`)
- #72309 (Some renaming and minor refactoring for `NativeLibraryKind`)
- #72438 (Enable ARM TME (Transactional Memory Extensions))
Ralf Jung [Fri, 22 May 2020 06:54:51 +0000 (08:54 +0200)]
Rollup merge of #72304 - petrochenkov:sgxunwind, r=nikomatsakis,jethrogb,dingelish
rustc_target: Avoid an inappropriate use of `post_link_objects`
It isn't supposed to be used for linking libraries.
Also linking libunwind unconditionally (and not together with the `src/libunwind` crate) is suspicious.
@jethrogb @VardhanThigle
Could you verify that it works as expected?
Ralf Jung [Fri, 22 May 2020 06:54:49 +0000 (08:54 +0200)]
Rollup merge of #72133 - bdbai:master, r=joshtriplett
Add target thumbv7a-uwp-windows-msvc
Add target spec for thumbv7a-uwp-windows-msvc, so that libraries written in Rust will have a chance to run on ARM-based devices with Windows 10.
So far I managed to create a proof-of-concept library for Universal Windows Platform apps to consume and it worked on a Windows Phone. However, building a standalone executable seemed troublesome due to `LLVM ERROR: target does not implement codeview register mapping` stuff (see also https://github.com/rust-lang/rust/issues/52659#issuecomment-408233322 ).
Steps to test:
1. Clone and build this version
```sh
git clone https://github.com/bdbai/rust.git
cd rust
python x.py build -i --target thumbv7a-uwp-windows-msvc --stage 1 src/libstd
rustup toolchain link arm-uwp-stage1 .\build\x86_64-pc-windows-msvc\stage1\
```
2. Create a new library crate
```sh
cargo new --lib arm-uwp-test
cd arm-uwp-test
```
3. Change `crate-type` in `Cargo.toml` to `staticlib`
```toml
[lib]
crate-type=["staticlib"]
```
4. Replace the following code in `src/lib.rs`
```rust
#[no_mangle]
pub extern "system" fn call_rust() -> i32 {
2333
}
```
5. Build the crate
```sh
cargo +arm-uwp-stage1 build -v --target thumbv7a-uwp-windows-msvc
```
6. `arm-uwp-test.lib` should appear in `target\thumbv7a-uwp-windows-msvc\debug`
To consume this library:
1. Make sure Visual Studio 2017 and Windows 10 SDK (10.0.17134 or above) are installed
2. Create a new Blank App (C++/WinRT) in Visual Studio 2017 (Visual Studio 2019 cannot deploy UWP apps to Windows Phone)
3. Go to Property Pages, and then Linker->Input->Additional Dependencies, add `arm-uwp-test.lib` produced just now
4. Manually declare function prototypes in `MainPage.h`
```c++
extern "C" {
int call_rust();
}
```
5. Replace the `ClickHandler` part in `MainPage.cpp`
```c++
myButton().Content(box_value(std::to_wstring(call_rust())));
```
6. Build and deploy this app to an ARM device running Windows 10. The app should run and show `2333` when the button is clicked.
bors [Fri, 22 May 2020 04:52:38 +0000 (04:52 +0000)]
Auto merge of #72000 - cuviper:dist-llvm, r=Mark-Simulacrum
Move the target libLLVM to llvm-tools-preview
For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.
Here are the dist sizes that I got before and after this change:
bors [Fri, 22 May 2020 01:32:42 +0000 (01:32 +0000)]
Auto merge of #71956 - ecstatic-morse:remove-requires-storage-analysis, r=tmandry
Clean up logic around live locals in generator analysis
Resolves #69902. Requires #71893.
I've found it difficult to make changes in the logic around live locals in `generator/transform.rs`. It uses a custom dataflow analysis, `MaybeRequiresStorage`, that AFAICT computes whether a local is either initialized or borrowed. That analysis is using `before` effects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday.
This PR replaces `MaybeRequiresStorage` with a combination of the existing `MaybeBorrowedLocals` and a new `MaybeInitializedLocals`. `MaybeInitializedLocals` is just `MaybeInitializedPlaces` with a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic in `compute_storage_conflicts` and `locals_live_across_suspend_points`.
This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the `mixed_sizes` future couldn't be 5K. It went from 7K to 6K in this PR.
Ralf Jung [Thu, 21 May 2020 19:10:41 +0000 (21:10 +0200)]
Rollup merge of #72350 - danielhenrymantilla:doc_warn_against_adjacent_slice_concat, r=RalfJung
Improve documentation of `slice::from_raw_parts`
This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.
Providing that very pattern as a counter-example could help mitigate that.
See also: https://internals.rust-lang.org/t/pre-rfc-add-join-seq-method-to-slices-and-strs/11936/13
Ralf Jung [Thu, 21 May 2020 19:10:36 +0000 (21:10 +0200)]
Rollup merge of #72055 - lcnr:predicate-kind, r=nikomatsakis
Intern predicates
Implements the first step of https://github.com/rust-lang/compiler-team/issues/285
Renames `ty::Predicate` to `ty::PredicateKind`, which is now interned.
To ease the transition, `ty::Predicate` is now a struct containing a reference
to `ty::PredicateKind`.
In order to remove the use of `TyKind::Error`, I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however, since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct, that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model.
As usual, I tried to separate commits that shuffle code around from commits that require more thought to review.
This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.
Providing that very pattern as a counter-example could help mitigate that.
bors [Thu, 21 May 2020 15:02:08 +0000 (15:02 +0000)]
Auto merge of #71718 - NeoRaider:ffi_const_pure, r=Amanieu
Experimentally add `ffi_const` and `ffi_pure` extern fn attributes
Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`.
Rebased version of #58327 by @gnzlbg with the following changes:
- Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with https://github.com/rust-lang/rust/pull/58327#issuecomment-462718772 and this nicely aligns with `ffi_returns_twice`
- (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR
bors [Thu, 21 May 2020 11:46:51 +0000 (11:46 +0000)]
Auto merge of #72422 - RalfJung:rollup-u81z4mw, r=RalfJung
Rollup of 7 pull requests
Successful merges:
- #71854 (Make `std::char` functions and constants associated to `char`.)
- #72111 (rustc-book: Document `-Z strip=val` option)
- #72272 (Fix going back in history to a search result page on firefox)
- #72296 (Suggest installing VS Build Tools in more situations)
- #72365 (Remove unused `StableHashingContext::node_to_hir_id` method)
- #72371 (FIX - Char documentation for unexperienced users)
- #72397 (llvm: Expose tiny code model to users)
Ralf Jung [Thu, 21 May 2020 11:12:24 +0000 (13:12 +0200)]
Rollup merge of #72397 - petrochenkov:tiny, r=Amanieu
llvm: Expose tiny code model to users
This model is relevant to embedded AArch64 targets and was added to LLVM relatively recently (https://reviews.llvm.org/D49673, mid 2018), so rustc frontend didn't provide access to it with `-C code-model`. The gcc analogue is [`-mcmodel=tiny`](https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html).
(This is one of the options that are passed directly to LLVM without being interpreted by rustc.)
Follow up to https://github.com/rust-lang/rust/pull/72248.
Ralf Jung [Thu, 21 May 2020 11:12:22 +0000 (13:12 +0200)]
Rollup merge of #72371 - Elrendio:char_documentation, r=steveklabnik
FIX - Char documentation for unexperienced users
This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure.
**What it does:**
- Add an example in the char documentation
**Explanation**
Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write:
```rust
my_string.chars().all(char::is_uppercase)
```
However this will return false for `"HELLO WORLD"` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is:
```rust
!my_string.chars().any(char::is_lowercase)
```
The aim of this example is to prevent unexperienced users to make an error which punctuation chars.
Ralf Jung [Thu, 21 May 2020 11:12:19 +0000 (13:12 +0200)]
Rollup merge of #72296 - ChrisDenton:msvc-link-check, r=petrochenkov
Suggest installing VS Build Tools in more situations
When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected.
Ralf Jung [Thu, 21 May 2020 11:12:17 +0000 (13:12 +0200)]
Rollup merge of #72272 - GuillaumeGomez:fix-back-on-page-with-search-behaviour, r=kinnison
Fix going back in history to a search result page on firefox
This bug was actually firefox not re-running JS script when you go back in history. To trigger it on the current docs:
* Make a search
* Pick an element (which isn't on the same page as the current element!)
* Go back in history
Instead of having the search results, you'll see the normal doc page. You can find a small explanation about it [here](http://web.archive.org/web/20100428053932/http://www.firefoxanswer.com/firefox/672-firefoxanswer.html).
bors [Thu, 21 May 2020 07:16:44 +0000 (07:16 +0000)]
Auto merge of #72205 - ecstatic-morse:nrvo, r=oli-obk
Dumb NRVO
This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.
I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.
bors [Thu, 21 May 2020 03:48:47 +0000 (03:48 +0000)]
Auto merge of #70705 - lcnr:generic_discriminant, r=nikomatsakis
Use `T`'s discriminant type in `mem::Discriminant<T>` instead of `u64`.
fixes #70509
Adds the lang-item `discriminant_kind`.
Updates the function signature of `intrinsics::discriminant_value`.
Adds the *probably permanently unstable* trait `DiscriminantKind`.
`mem::Discriminant` should now be smaller in some cases.
Josh Stone [Fri, 8 May 2020 00:27:08 +0000 (17:27 -0700)]
Move the target libLLVM to llvm-tools-preview
For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.
Here are the dist sizes that I got before and after this change:
bors [Wed, 20 May 2020 22:49:57 +0000 (22:49 +0000)]
Auto merge of #67759 - nikic:llvm-10, r=Mark-Simulacrum
Update to LLVM 10
LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;)
Status:
* Preparation split off into #67900.
* Optimization regressions:
* [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed.
* [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed.
* [x] https://reviews.llvm.org/D72169 submitted.
* [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted, but unlikely eligible for LLVM 10.
* Compile-time regressions:
* [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch.
* [ ] Even with the revert, there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14).
* Assertion failures / infinite loops:
* [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135, https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch.
* [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.
Chris Denton [Sun, 17 May 2020 14:22:47 +0000 (15:22 +0100)]
Suggest installing VS Build Tools in more situations
When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.
Dylan DPC [Wed, 20 May 2020 12:21:06 +0000 (14:21 +0200)]
Rollup merge of #72139 - nnethercote:standalone-fold, r=cuviper
Make `fold` standalone.
`fold` is currently implemented via `try_fold`, but implementing it
directly results in slightly less LLVM IR being generated, speeding up
compilation of some benchmarks.
bors [Wed, 20 May 2020 05:47:10 +0000 (05:47 +0000)]
Auto merge of #71769 - petrochenkov:crto, r=cuviper
linker: More systematic handling of CRT objects
Document which kinds of `crt0.o`-like objects we link and in which cases, discovering bugs in process.
`src/librustc_target/spec/crt_objects.rs` is the place to start reading from.
This PR also automatically contains half of the `-static-pie` support (https://github.com/rust-lang/rust/pull/70740), because that's one of the six cases that we need to consider when linking CRT objects.
This is a breaking change for custom target specifications that specify CRT objects.
bors [Wed, 20 May 2020 02:22:44 +0000 (02:22 +0000)]
Auto merge of #72339 - ehuss:update-cargo, r=ehuss
Update cargo
9 commits in cb06cb2696df2567ce06d1a39b1b40612a29f853..500b2bd01c958f5a33b6aa3f080bea015877b83c
2020-05-08 21:57:44 +0000 to 2020-05-18 17:12:54 +0000
- Handle LTO with an rlib/cdylib crate type (rust-lang/cargo#8254)
- Gracefully handle errors during a build. (rust-lang/cargo#8247)
- Update `im-rc` to 15.0.0 (rust-lang/cargo#8255)
- Fix `cargo update` with unused patch. (rust-lang/cargo#8243)
- Rephrased error message for disallowed sections in virtual workspace (rust-lang/cargo#8200)
- Ignore broken console output in some situations. (rust-lang/cargo#8236)
- Expand error message to explain that a string was found (rust-lang/cargo#8235)
- Add context to some fs errors. (rust-lang/cargo#8232)
- Move SipHasher to an isolated module. (rust-lang/cargo#8233)
Dylan MacKenzie [Wed, 13 May 2020 16:45:00 +0000 (09:45 -0700)]
Document why we don't look at storage liveness
...when determining what locals are live.
A local cannot be borrowed before it is `storage_live` and
`MaybeBorrowedLocals` already invalidates borrows on `StorageDead`.
Likewise, a local cannot be initialized before it is marked StorageLive
and is marked as uninitialized after `StorageDead`.
Dylan MacKenzie [Wed, 13 May 2020 16:42:56 +0000 (09:42 -0700)]
Document assumptions made in generator transform for analyses
The generator transform needs to inspect all possible dataflow states.
This can be done with half the number of bitset union operations if we
can assume that the relevant analyses do not use "before" effects.
Dylan MacKenzie [Wed, 6 May 2020 18:38:59 +0000 (11:38 -0700)]
Clean up generator live locals analysis
Instead of using a bespoke dataflow analysis, `MaybeRequiresStorage`,
for computing locals that need to be stored across yield points and that
have conflicting storage, use a combination of simple, generally
applicable dataflow analyses. In this case, the formula for locals
that are live at a yield point is:
and the formula for locals that require storage (and thus may conflict
with others) at a given point is:
requires_storage := init | borrowed
`init` is `MaybeInitializedLocals`, a direct equivalent of
`MaybeInitializedPlaces` that works only on whole `Local`s. `borrowed`
and `live` are the pre-existing `MaybeBorrowedLocals` and
`MaybeLiveLocals` analyses respectively.
Aaron Hill [Sun, 17 May 2020 19:51:01 +0000 (15:51 -0400)]
Break tokens before checking if they are 'probably equal'
Fixes #68489
When checking two `TokenStreams` to see if they are 'probably equal',
we ignore the `IsJoint` information associated with each `TokenTree`.
However, the `IsJoint` information determines whether adjacent tokens
will be 'glued' (if possible) when construction the `TokenStream` - e.g.
`[Gt Gt]` can be 'glued' to `BinOp(Shr)`.
Since we are ignoring the `IsJoint` information, 'glued' and 'unglued'
tokens are equivalent for determining if two `TokenStreams` are
'probably equal'. Therefore, we need to 'unglue' all tokens in the
stream to avoid false negatives (which cause us to throw out the cached
tokens, losing span information).