Ralf Jung [Sun, 24 May 2020 14:51:30 +0000 (16:51 +0200)]
Rollup merge of #72527 - RalfJung:miri-clippy-test-args, r=Mark-Simulacrum
bootstrap: propagate test-args to miri and clippy test suites
For Miri I verified this works. For clippy, unfortunately it doesn't seem to work as a stage 0 tool:
```
./x.py --stage 0 test src/tools/clippy --test-args init
```
gives
```
Compiling clippy-mini-macro-test v0.2.0 (/home/r/src/rust/rustc.3/src/tools/clippy/mini-macro)
error[E0658]: procedural macros cannot be expanded to expressions
--> src/tools/clippy/mini-macro/src/lib.rs:11:5
|
11 | / quote!(
12 | | #[allow(unused)]
13 | | fn needless_take_by_value(s: String) {
14 | | println!("{}", s.len());
... |
24 | | }
25 | | )
| |_____^
|
= note: see issue #54727 <https://github.com/rust-lang/rust/issues/54727> for more information
= help: add `#![feature(proc_macro_hygiene)]` to the crate attributes to enable
Compiling proc-macro2 v1.0.3
Compiling syn v1.0.11
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
error: could not compile `clippy-mini-macro-test`.
```
But propagating `--test-args` to the test suite seems to make sense regardless.
Cc @rust-lang/clippy
Ralf Jung [Sun, 24 May 2020 10:17:09 +0000 (12:17 +0200)]
Rollup merge of #72284 - Aaron1011:feature/inline-macro-did, r=petrochenkov
Remove `macro_defs` map
We now store the `DefId` directly in `ExpnKind::Macro`. This will allow
us to serialize `ExpnData` in PR #72121 without needing to manage a side
table.
Ralf Jung [Sun, 24 May 2020 07:30:31 +0000 (09:30 +0200)]
Rollup merge of #72388 - Aaron1011:fix/deep-tokenstream-equality, r=petrochenkov
Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
Fixes #68430
When comparing the captured and re-parsed `TokenStream` for a `TokenKind::Interpolated`, we currently treat any nested `TokenKind::Interpolated` tokens as unequal. If a `TokenKind::Interpolated` token shows up in the captured `TokenStream` due to a `macro_rules!` expansion, we will throw away the captured `TokenStream`, losing span information.
This PR recursively invokes `nt_to_tokenstream` on nested `TokenKind::Interpolated` tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original captured `TokenStream` (with span information).
This requires all of the `probably_equal_for_proc_macro` methods to be moved from `librustc_ast` to `librustc_parse` so that they can call `nt_to_tokenstream`.
bors [Sun, 24 May 2020 04:15:08 +0000 (04:15 +0000)]
Auto merge of #72362 - matthewjasper:remove-rescope, r=nikomatsakis
Remove ReScope
`ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully.
bors [Sun, 24 May 2020 00:56:20 +0000 (00:56 +0000)]
Auto merge of #72516 - Dylan-DPC:rollup-cc4w96z, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #71618 (Preserve substitutions when making trait obligations for suggestions)
- #72092 (Unblock font loading in rustdoc.css)
- #72400 (Add missing ASM arena declarations to librustc_middle)
- #72489 (Fix ice-72487)
- #72502 (fix discriminant type in generator transform)
Dylan DPC [Sat, 23 May 2020 22:00:52 +0000 (00:00 +0200)]
Rollup merge of #72502 - RalfJung:generator-discr-ty, r=jonas-schievink
fix discriminant type in generator transform
The generator transform assumed that the discriminant type is always `isize`, which is not correct, leading to [ICEs in Miri](https://github.com/rust-lang/rust/pull/72419/files#r429543536) when some extra sanity checking got enabled.
Dylan DPC [Sat, 23 May 2020 22:00:48 +0000 (00:00 +0200)]
Rollup merge of #72400 - Aaron1011:fix/asm-incr-ice, r=Amanieu
Add missing ASM arena declarations to librustc_middle
Fixes #72386
These types also need to get allocated on the `librustc_middle` arena
when we deserialize MIR.
@Amanieu: If we end up using your approach in https://github.com/rust-lang/rust/pull/72392 instead, feel free to copy the test I added over to your PR.
Dylan DPC [Sat, 23 May 2020 22:00:45 +0000 (00:00 +0200)]
Rollup merge of #72092 - workingjubilee:patch-2, r=GuillaumeGomez
Unblock font loading in rustdoc.css
rustdoc's font loading defaults to "auto", so browsers may block render.
But rustdoc's case prefers a faster TTI for scrolling, this means the
strictest font-display in use should be "swap". rustdoc's fonts do provide
notable legibility improvements but first-time users will have little trouble
reading without. This means "optional" is preferred.
The one exception is Source Serif Pro: it's a big difference for body text, so
"fallback" is preferred over "optional" to cause a (tiny) block.
This follows up on (but does not resolve) #20962, taking PageSpeed Insight's rec fairly directly. Supporting reading material: https://drafts.csswg.org/css-fonts-4/#font-display-desc
Dylan DPC [Sat, 23 May 2020 22:00:42 +0000 (00:00 +0200)]
Rollup merge of #71618 - ecstatic-morse:issue-71394, r=nikomatsakis
Preserve substitutions when making trait obligations for suggestions
Resolves #71394.
I *think* `map_bound_ref` is correct here. In any case, I think a lot of the diagnostic code is using `skip_binder` more aggressively than it should be, so I doubt that this is worse than the status quo. The assertion that `new_self_ty` has no escaping bound vars should be enough.
r? @estebank
cc @nikomatsakis Is the call to `skip_binder` on line 551 (and elsewhere in this file) appropriate? https://github.com/rust-lang/rust/blob/46ec74e60f238f694b46c976d6217e7cf8d4cf1a/src/librustc_trait_selection/traits/error_reporting/suggestions.rs#L537-L565
bors [Sat, 23 May 2020 21:21:40 +0000 (21:21 +0000)]
Auto merge of #72474 - mati865:ci-fix, r=pietroalbini
Revert MSYS2 CI workaround
MSYS2 has made workaround for critical packages so older installers like one used by chocolatey can work again.
Fixes https://github.com/rust-lang/rust/issues/72333
bors [Sat, 23 May 2020 17:53:54 +0000 (17:53 +0000)]
Auto merge of #72504 - Dylan-DPC:rollup-6wi1ifz, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #72292 (Replace obligation construction with deref_steps())
- #72431 (add warning sign to UB examples)
- #72446 (Impl Ord for proc_macro::LineColumn)
- #72492 (Add some regression tests)
- #72496 (Correct small typo: 'not' -> 'note')
Dylan DPC [Sat, 23 May 2020 17:10:00 +0000 (19:10 +0200)]
Rollup merge of #72446 - dtolnay:ord, r=petrochenkov
Impl Ord for proc_macro::LineColumn
```rust
impl Ord for LineColumn {...}
impl PartialOrd for LineColumn {...}
```
for https://doc.rust-lang.org/nightly/proc_macro/struct.LineColumn.html.
The ordering is the natural one you would get by writing one line after another, where we compare line first, then compare columns within the same line.
Dylan DPC [Sat, 23 May 2020 17:09:57 +0000 (19:09 +0200)]
Rollup merge of #72292 - ldm0:derefsteps, r=estebank
Replace obligation construction with deref_steps()
1. Use `probe()` to avoid unwanted binding committing during `deref_steps()`.
2. Fixes #59819 again by using `deref_steps()`, make the code cleaner. And if we want to suggest multiple dereferences (like: `consider dereferencing the borrow: "****a"`) in the future, this change will make it easier to achieve.
bors [Sat, 23 May 2020 07:18:17 +0000 (07:18 +0000)]
Auto merge of #72478 - Dylan-DPC:rollup-vval8du, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #71289 (Allow using `Self::` in doc)
- #72375 (Improve E0599 explanation)
- #72385 (Add some teams to prioritization exclude_labels)
- #72395 (Allow rust-highfive to label issues it creates.)
- #72453 (Add flag to open docs: x.py doc --open)
- #72459 (Add core::future::IntoFuture)
- #72461 (Clean up E0600 explanation)
bors [Sat, 23 May 2020 03:30:07 +0000 (03:30 +0000)]
Auto merge of #72256 - ecstatic-morse:once-cell, r=Mark-Simulacrum
Use `once_cell` crate instead of custom data structure
Internally, we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate, which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one.
This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver`, is owned by a well-known community member (cc @matklad), and has a stable release. cc @rust-lang/compiler
`once_cell` has a slightly more minimal API than `Once`, which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`.
Ensure that `new_self_ty` has no escaping bound vars
Otherwise inserting it to the `Binder` used by `trait_ref` would cause
problems. This is just to be extra carefult: we aren't going to
start recommending that the user start using HKTs anytime soon.
Preserve substitutions when trying to prove trait obligation
`mk_obligation_for_def_id` is only correct if the trait and self type do
not have any substitutions. Use a different method,
`mk_trait_obligation_with_new_self_ty` that is more clear about what is
happening.
Dylan DPC [Fri, 22 May 2020 19:45:01 +0000 (21:45 +0200)]
Rollup merge of #72459 - yoshuawuyts:into-future, r=nikomatsakis
Add core::future::IntoFuture
This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!
cc/ @rust-lang/wg-async-foundations
## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644
David Tolnay [Fri, 22 May 2020 16:50:41 +0000 (09:50 -0700)]
Report error from opener in bootstrap
On my machine, an error looks like:
Finished release [optimized] target(s) in 0.29s
Opening doc /git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html
command 'xdg-open (internal)' did not execute successfully; exit code: 4
command stderr:
gio: file:///git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html: Error when getting information for file “/git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html”: No such file or directory
bors [Fri, 22 May 2020 15:33:32 +0000 (15:33 +0000)]
Auto merge of #72464 - RalfJung:rollup-xhm7w7u, r=RalfJung
Rollup of 7 pull requests
Successful merges:
- #71829 (Fix suggestion to borrow in struct)
- #72123 (Stabilize process_set_argv0 feature for Unix)
- #72235 (Clean up E0590 explanation)
- #72345 (Clean up E0593 explanation)
- #72376 ([self-profling] Record the cgu name when doing codegen for a module)
- #72399 (Add fast-path optimization for Ipv4Addr::fmt)
- #72435 (rustllvm: Fix warnings about unused function parameters)
Ralf Jung [Fri, 22 May 2020 14:58:19 +0000 (16:58 +0200)]
Rollup merge of #71829 - kper:issue71136, r=matthewjasper
Fix suggestion to borrow in struct
The corresponding issue is #71136.
The compiler suggests that borrowing `the_foos` might solve the problem. This is obviously incorrect.
```
struct Foo(u8);
I propose as fix to check if there is any colon in the span. However, there might a case where `my_method(B { a: 1, b : foo })` would be appropriate to show a suggestion for `&B ...`. To fix that too, we can simply check if there is a bracket in the span. This is only possible because both spans are different.
Issue's span: `the_foos: Vec<Foo>`
other's span: `B { a : 1, b : foo }`
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.
Yoshua Wuyts [Fri, 22 May 2020 08:07:46 +0000 (10:07 +0200)]
Add core::future::IntoFuture
This patch adds `core::future::IntoFuture`. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering. That integration should be done in a follow-up PR.
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:
projects / rust.git / log