Rollup merge of #63699 - gilescope:async-move-diagnostic, r=estebank
Fix suggestion from incorrect `move async` to `async move`.
PR for #61920. Happy with the test. There must be a better implementation though - possibly a MIR visitor to estabilsh a span that doesn't include the `async` keyword?
Rollup merge of #63376 - nikomatsakis:async-await-issue-62517, r=cramertj
use different lifetime name for object-lifetime-default elision
Introduce a distinct value for `LifetimeName` to use when this is a object-lifetime-default elision. This allows us to avoid creating incorrect lifetime parameters for the opaque types that result. We really need to overhaul this setup at some point! It's getting increasingly byzantine. But this seems like a relatively... surgical fix.
Rollup merge of #63252 - nrc:arc-doc, r=alexcrichton
Remove recommendation about idiomatic syntax for Arc::clone
I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs.
The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls.
Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional.
The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years.
The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case).
cc @nical (who added the docs in the first place; sorry :-) )
r? @alexcrichton (or someone else on @rust-lang/libs )
Niko Matsakis [Mon, 12 Aug 2019 14:41:05 +0000 (10:41 -0400)]
use static as object-lifetime default for type XX in `Foo<Item=XX>`
Currently the default is "inherited" from context, so e.g. `&impl
Foo<Item = dyn Bar>` would default to `&'x impl Foo<Item = dyn Bar +
'x>`, but this triggers an ICE and is not very consistent.
This patch doesn't implement what I expect would be the correct
semantics, because those are likely too complex. Instead, it handles
what I'd expect to be the common case -- where the trait has no
lifetime parameters.
Niko Matsakis [Thu, 8 Aug 2019 07:36:24 +0000 (03:36 -0400)]
distinguish object-lifetime-default elision from other elision
Object-lifetime-default elision is distinct from other forms of
elision; it always refers to some enclosing lifetime *present in the
surrounding type* (e.g., `&dyn Bar` expands to `&'a (dyn Bar + 'a)`.
If there is no enclosing lifetime, then it expands to `'static`.
Therefore, in an `impl Trait<Item = dyn Bar>` setting, we don't expand
to create a lifetime parameter for the `dyn Bar + 'X` bound. It will
just be resolved to `'static`.
Annoyingly, the responsibility for this resolution is spread across
multiple bits of code right now (`middle::resolve_lifetimes`,
`lowering`). The lowering code knows that the default is for an object
lifetime, but it doesn't know what the correct result would be.
Probably this should be fixed, but what we do now is a surgical fix:
we have it generate a different result for elided lifetimes in a
object context, and then we can ignore those results when figuring out
the lifetimes that are captured in the opaque type.
bors [Mon, 19 Aug 2019 17:04:10 +0000 (17:04 +0000)]
Auto merge of #63579 - alexcrichton:new-lockfile, r=Mark-Simulacrum
Use to Cargo's experimental lockfile format
This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.
The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.
It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.
Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.
Alex Crichton [Thu, 15 Aug 2019 00:45:09 +0000 (17:45 -0700)]
Use to Cargo's experimental lockfile format
This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.
The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.
It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.
Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.
bors [Mon, 19 Aug 2019 13:17:34 +0000 (13:17 +0000)]
Auto merge of #63700 - alexcrichton:update-backtrace, r=sfackler
std: Update `backtrace` crate dependency
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The
[included set of changes][changes] for this update mostly includes some
gimli-related improvements (not relevant for the standard library) but
critically includes a fix for rust-lang/backtrace-rs#230. The standard
library will not aqcuire a session-local lock whenever a backtrace is
generated on Windows to allow external synchronization with the
`backtrace` crate itself, allowing `backtrace` to be safely used while
other threads may be panicking.
Alex Crichton [Mon, 19 Aug 2019 13:13:18 +0000 (06:13 -0700)]
std: Update `backtrace` crate dependency
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The
[included set of changes][changes] for this update mostly includes some
gimli-related improvements (not relevant for the standard library) but
critically includes a fix for rust-lang/backtrace-rs#230. The standard
library will not aqcuire a session-local lock whenever a backtrace is
generated on Windows to allow external synchronization with the
`backtrace` crate itself, allowing `backtrace` to be safely used while
other threads may be panicking.
bors [Mon, 19 Aug 2019 01:31:35 +0000 (01:31 +0000)]
Auto merge of #63463 - matthewjasper:ty_param_cleanup, r=petrochenkov
Don't special case the `Self` parameter by name
This results in a couple of small diagnostic regressions. They could be avoided by keeping the special case just for diagnostics, but that seems worse.
bors [Sun, 18 Aug 2019 22:01:21 +0000 (22:01 +0000)]
Auto merge of #63045 - Rosto75:master, r=jonas-schievink
Change the placement of two functions.
Right now, the order is as follows:
`pop_front()`
`push_front()`
`push_back()`
`pop_back()`
`swap_remove_back()`
`swap_remove_front()`
I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this:
`pop_front()`
`pop_back()`
`push_front()`
`push_back()`
`swap_remove_front()`
`swap_remove_back()`
The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.
bors [Sun, 18 Aug 2019 08:15:38 +0000 (08:15 +0000)]
Auto merge of #63269 - Aaron1011:feature/proc-macro-data, r=eddyb,petrochenkov
Serialize additional data for procedural macros
Split off from #62855
This PR serializes the declaration `Span` and attributes for all
procedural macros. This allows Rustdoc to properly render doc comments
and source links when performing inlinig procedural macros across crates
Rollup merge of #63667 - petrochenkov:deriveholders, r=matthewjasper
resolve: Properly integrate derives and `macro_rules` scopes
So,
```rust
#[derive(A, B)]
struct S;
m!();
```
turns into something like
```rust
struct S;
A_placeholder!( struct S; );
B_placeholder!( struct S; );
m!();
```
during expansion.
And for `m!()` its "`macro_rules` scope" (aka "legacy scope") should point to the `B_placeholder` call rather than to the derive container `#[derive(A, B)]`.
`fn build_reduced_graph` now makes sure the legacy scope points to the right thing.
(It's still a mystery for me why this worked before https://github.com/rust-lang/rust/pull/63535.)
Unfortunately, placeholders from derives are currently treated separately from placeholders from other macros and need to be passed as `extra_placeholders` rather than a part of the AST fragment.
That's fixable, but I wanted to keep this PR more minimal to close the regression faster.
Rollup merge of #63657 - RalfJung:invalid_value, r=Centril
Crank up invalid value lint
* Warn against uninit `bool` and `char`.
* Warn against 0-init `NonNull` and friends
* Detect transmute-from-0 as zero-initialization ([seen in the wild](https://github.com/glium/glium/issues/1775#issuecomment-522144636))
Rollup merge of #62451 - SimonSapin:new_uninit, r=RalfJung
Add APIs for uninitialized Box, Rc, and Arc. (Plus get_mut_unchecked)
Assigning `MaybeUninit::<Foo>::uninit()` to a local variable is usually free, even when `size_of::<Foo>()` is large. However, passing it for example to `Arc::new` [causes at least one copy](https://youtu.be/F1AquroPfcI?t=4116) (from the stack to the newly allocated heap memory) even though there is no meaningful data. It is theoretically possible that a Sufficiently Advanced Compiler could optimize this copy away, but this is [reportedly unlikely to happen soon in LLVM](https://youtu.be/F1AquroPfcI?t=5431).
This PR proposes two sets of features:
* Constructors for containers (`Box`, `Rc`, `Arc`) of `MaybeUninit<T>` or `[MaybeUninit<T>]` that do not initialized the data, and unsafe conversions to the known-initialized types (without `MaybeUninit`). The constructors are guaranteed not to make unnecessary copies.
* On `Rc` and `Arc`, an unsafe `get_mut_unchecked` method that provides `&mut T` access without checking the reference count. `Arc::get_mut` involves multiple atomic operations whose cost can be non-trivial. `Rc::get_mut` is less costly, but we add `Rc::get_mut_unchecked` anyway for symmetry with `Arc`.
These can be useful independently, but they will presumably be typical when the new constructors of `Rc` and `Arc` are used.
An alternative with a safe API would be to introduce `UniqueRc` and `UniqueArc` types that have the same memory layout as `Rc` and `Arc` (and so zero-cost conversion to them) but are guaranteed to have only one reference. But introducing entire new types feels “heavier” than new constructors on existing types, and initialization of `MaybeUninit<T>` typically requires unsafe code anyway.
bors [Sat, 17 Aug 2019 17:53:31 +0000 (17:53 +0000)]
Auto merge of #63658 - RalfJung:miri-op, r=oli-obk
Refactor Miri ops (unary, binary) to have more types
This is the part of https://github.com/rust-lang/rust/pull/63448 that is just a refactoring. It helps that PR by making it easier to perform machine arithmetic.
Aaron Hill [Sun, 4 Aug 2019 20:41:01 +0000 (16:41 -0400)]
Serialize additional data for procedural macros
Split off from #62855
This PR deerializes the declaration `Span` and attributes for all
procedural macros from their underlying function definitions.
This allows Rustdoc to properly render doc comments
and source links when inlining procedural macros across crates
bors [Sat, 17 Aug 2019 12:53:53 +0000 (12:53 +0000)]
Auto merge of #63462 - matthewjasper:hygienic-builtin-derives, r=petrochenkov
Opaque builtin derive macros
* Buiilt-in derives are now opaque macros
* This required limiting the visibility of some previously unexposed functions in `core`.
* This also required the change to `Ident` serialization.
* All gensyms are replaced with hygienic identifiers
* Use hygiene to avoid most other name-resolution issues with buiilt-in derives.
* As far as I know the only remaining case that breaks is an ADT that has the same name as one of its parameters. Fixing this completely seemed to be more effort than it's worth.
* Remove gensym in `Ident::decode`, which lead to linker errors due to `inline` being gensymmed.
* `Ident`now panics if incremental compilation tries to serialize it (it currently doesn't).
* `Ident` no longer uses `gensym` to emulate cross-crate hygiene. It only applied to reexports.
* `SyntaxContext` is no longer serializable.
* The long-term fix for this is to properly implement cross-crate hygiene, but this seemed to be acceptable for now.
* Move type/const parameter shadowing checks to `resolve`
* This was previously split between resolve and type checking. The type checking pass compared `InternedString`s, not Identifiers.
* Removed the `SyntaxContext` from `{ast, hir}::{InlineAsm, GlobalAsm}`
bors [Sat, 17 Aug 2019 09:14:37 +0000 (09:14 +0000)]
Auto merge of #63655 - Centril:rollup-ty1ot40, r=Centril
Rollup of 4 pull requests
Successful merges:
- #62737 (Override Cycle::try_fold)
- #63505 (Hash the remapped sysroot instead of the original.)
- #63559 (rustc_codegen_utils: account for 1-indexed anonymous lifetimes in v0 mangling.)
- #63621 (Modify librustc_llvm to pass -DNDEBUG while compiling.)
Rollup merge of #63621 - jgalenson:dndebug, r=alexcrichton
Modify librustc_llvm to pass -DNDEBUG while compiling.
Currently, librustc_llvm builds are not reproducible because the LLVM files it compiles use the debug version of llvm_unreachable, which uses __FILE__. To fix this, we propagate NDEBUG from bootstrap if applicable and use it when compiling librustc_llvm.
Rollup merge of #63559 - eddyb:v0-mangling-off-by-1, r=estebank
rustc_codegen_utils: account for 1-indexed anonymous lifetimes in v0 mangling.
I don't really understand why `anonymize_late_bound_regions` starts with `BrAnon(1)` instead of `BrAnon(0)`, but it does (maybe @nikomatsakis knows?): https://github.com/rust-lang/rust/blob/c43d03a19f326f4a323569328cc501e86eb6d22e/src/librustc/ty/fold.rs#L696-L712
Thankfully, the mangling format and demangler implementations are fine, and I just needed to offset the anonymized lifetime indices by `1` to get the correct mangling.
Rollup merge of #63505 - jgalenson:sysroot-hash, r=alexcrichton
Hash the remapped sysroot instead of the original.
One of the reasons that rustc builds are not reproducible is because the --sysroot path is dependent on the current directory. We can fix this by hashing the remapped sysroot instead of the original when applicable.
Note that with this patch, the hash will stay the same if both the sysroot and the remapped path change. However, given that if the contents of the sysroot change the hash will also stay the same, this might be acceptable. I would appreciate feedback on the best way to do this.
This helps #34902, although it does not fix it by itself.
Rollup merge of #62737 - timvermeulen:cycle_try_fold, r=scottmcm
Override Cycle::try_fold
It's not very pretty, but I believe this is the simplest way to correctly implement `Cycle::try_fold`. The following may seem correct:
```rust
loop {
acc = self.iter.try_fold(acc, &mut f)?;
self.iter = self.orig.clone();
}
```
...but this loops infinitely in case `self.orig` is empty, as opposed to returning `acc`. So we first have to fully iterate `self.orig` to check whether it is empty or not, and before _that_, we have to iterate the remaining elements of `self.iter`.
This should always call `self.orig.clone()` the same amount of times as repeated `next()` calls would.
Matthew Jasper [Sun, 11 Aug 2019 10:48:22 +0000 (11:48 +0100)]
Stop emulating cross-crate hygiene with gensyms
Most `Ident`s are serialized as `InternedString`s the exceptions are:
* Reexports
* Attributes
* Idents in macro definitions
Using gensyms helped reexports emulate hygiene. However, the actual item
wouldn't have a gensymmed name so would be usable cross-crate. So
removing this case until we have proper cross-crate hygiene seems
sensible.
Codegen attributes (`inline`, `export_name`) are resolved by their
`Symbol`. This meant that opaque macro-expanded codegen attributes could
cause linker errors. This prevented making built-in derives hygienic.
bors [Sat, 17 Aug 2019 04:47:20 +0000 (04:47 +0000)]
Auto merge of #63491 - Xanewok:update-rls, r=Mark-Simulacrum
Update RLS
This fixes handling default configuration for the `crate_blacklist`
RLS configuration.
Technically this isn't needed, as the VS Code extension can be
configured to accept a predefined blacklist that's equal to the default
one but it's best that it also lands so that we don't need to work
around that.
Without this, manually passing a `null` value as the configuration
unfortunately crashes the RLS. This is the last fix related to configuration.
Rollup merge of #63641 - DieracDelta:master, r=eddyb
add git keyword to submodule comments in config.example.toml
I searched over config.example.toml file looking for a place to disable git submodules from being updated, and missed the two options related to this because they did not include the keyword git. This pr simply adds git to the relevant comments so hopefully others won't also miss that these options exist.
Rollup merge of #63558 - jgalenson:move-remap, r=alexcrichton
Remap paths for proc-macro crates.
The remap-debuginfo config option remaps paths in most crates, but it does not apply to proc-macros, so they are still non-reproducible. This patch fixes that.
I'm not completely sure if this is the best way to do this, but to get reproducible builds we need librustc_macros to be built with --remap-path-prefix. I was previously modifying Cargo to pass that argument to all child crates, so this seems simpler and more correct.
I did not add a test since there do not seem to be any existing tests for RUSTC_DEBUGINFO_MAP.
Rollup merge of #63548 - eddyb:unicode-demangling, r=alexcrichton
Update rustc-demangle to 0.1.16.
Includes https://github.com/alexcrichton/rustc-demangle/pull/29 and https://github.com/alexcrichton/rustc-demangle/pull/30.
You can see the effects of the former in the testcase changes.
Rollup merge of #63149 - petrochenkov:lazypop2, r=eddyb
resolve: Populate external modules in more automatic and lazy way
So, resolve had this function `populate_module_if_necessary` for loading module children from other crates from metadata.
I never really understood when it should've been called and when not.
This PR removes the function and loads the module children automatically on the first access instead.
bors [Fri, 16 Aug 2019 18:35:17 +0000 (18:35 +0000)]
Auto merge of #63640 - Centril:rollup-yeb8o66, r=Centril
Rollup of 10 pull requests
Successful merges:
- #60492 (Add custom nth_back for Chain)
- #61780 (Finalize the error type for `try_reserve`)
- #63495 ( Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.)
- #63525 (Make sure that all file loading happens via SourceMap)
- #63595 (add sparc64-unknown-openbsd target)
- #63604 (Some update for vxWorks)
- #63613 (Hygienize use of built-in macros in the standard library)
- #63632 (A couple of comment fixes.)
- #63634 (ci: properly set the job name in CPU stats)
- #63636 (ci: move linkcheck from mingw-2 to mingw-1)
Move some code into `build_reduced_graph.rs` to keep `BuildReducedGraphVisitor` it private
Also move the def collector call to `build_reduced_graph.rs`, it belongs there.
Rollup merge of #63636 - pietroalbini:ci-mingw, r=alexcrichton
ci: move linkcheck from mingw-2 to mingw-1
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
Rollup merge of #63604 - Wind-River:master, r=alexcrichton
Some update for vxWorks
1. support crt-static
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf.
3. change vx-cxx to wr-c++, vx-ar to wr-ar and vx-run to wr-run.
4. code cleanup