Rollup merge of #67489 - Mark-Simulacrum:drop-petgraph, r=Centril
Drop petgraph dependency from bootstrap
It was essentially unused, likely leftover from a previous refactoring iteration. This should hopefully help reduce bootstrap build times a little, dropping petgraph, fixedbitset, and ordermap from the dependency set.
Rollup merge of #67469 - cuviper:no-default-rustc-dev, r=Mark-Simulacrum
Remove rustc-dev from the default nightly components
It was already filtered from other branches, but we only kept it in
nightly's default to ease the transition. Now that the separation of
rust-std/rustc-dev has reached the 1.40 release, it seems like a good
time for that transition to end.
Rollup merge of #67160 - matthewjasper:gat-generics, r=nikomatsakis
Make GATs less ICE-prone.
After this PR simple lifetime-generic associated types can now be used in a compiling program. There are two big limitations:
* #30472 has not been addressed in any way (see src/test/ui/generic-associated-types/iterable.rs)
* Using type- and const-generic associated types errors because bound types and constants aren't handled by trait solving.
* The errors are technically non-fatal, but they happen in a [part of the compiler](https://github.com/rust-lang/rust/blob/4abb0ad2731e9ac6fd5d64d4cf15b7c82e4b5a81/src/librustc_typeck/lib.rs#L298) that fairly aggressively stops compiling on errors.
15 commits in 626f0f40efd32e6b3dbade50cd53fdfaa08446ba..5a139f7e6d67fd8a416a3f19d8e01581d24c0333
2019-12-03 16:53:04 +0000 to 2019-12-10 20:17:50 +0000
- Bump cargo-platform version. (rust-lang/cargo#7693)
- Add a test for `cargo locate-project` (rust-lang/cargo#7690)
- Emit error on [target.'cfg(debug_assertions)'.dependencies] and similar (rust-lang/cargo#7660)
- Update the layout of `Cargo Commands` in doc (rust-lang/cargo#7687)
- Features and dependencies can't have the same name (rust-lang/cargo#7682)
- Fix some typos in doc (rust-lang/cargo#7672)
- Add test for `NAME` environment variable when `cargo new` (rust-lang/cargo#7667)
- Add test for `GIT_COMMITTER_EMAIL` when `cargo new` (rust-lang/cargo#7666)
- document support for Bitbucket Pipelines badges (rust-lang/cargo#7663)
- Add cargo-vendor to the list of cargo commands in doc (rust-lang/cargo#7659)
- Fix typo in section 'Caching the Cargo home in CI' (rust-lang/cargo#7661)
- Docs: Add an appendix on git authentication. (rust-lang/cargo#7658)
- Remove --offline empty index error. (rust-lang/cargo#7655)
- Change the link destination of cargo book contribution (rust-lang/cargo#7657)
- Add a --offline hint. (rust-lang/cargo#7654)
bors [Sat, 21 Dec 2019 14:30:26 +0000 (14:30 +0000)]
Auto merge of #67485 - Centril:rollup-gt0opvr, r=Centril
Rollup of 7 pull requests
Successful merges:
- #67059 (Fix too restrictive checks on Drop impls)
- #67355 (Merge `ast::Mutability` and `mir::Mutability`)
- #67393 (Enable opting out of specific default LLVM arguments.)
- #67422 (Cleanup err codes)
- #67462 (Make ptr::slice_from_raw_parts a const fn available under a feature flag)
- #67467 (Test slice patterns more)
- #67478 (Fix src/libcore/str/mod.rs doc comments)
Rollup merge of #67462 - DutchGhost:const_slice_from_raw_parts, r=dtolnay
Make ptr::slice_from_raw_parts a const fn available under a feature flag
A first step in the direction of https://github.com/rust-lang/rust/issues/67456 .
This makes `ptr::slice_from_raw_parts` and `ptr::slice_from_raw_parts_mut` available as a const fn under a feature flag.
Rollup merge of #67393 - michaelwoerister:llvm-args-override, r=varkor
Enable opting out of specific default LLVM arguments.
`rustc` by default adds a few arguments to LLVM (like `-mergefunc-use-aliases` for example). With this PR `rustc` will only emit these arguments if the same argument has not already been specified by the user via `-Cllvm-args`. This enables opting out of these defaults.
The PR also removes a PGO specific `-Z` flag the effect of which can also be easily achieved by `-Cllvm-args`.
Rollup merge of #67059 - TommasoBianchi:dropck_fix_pr, r=pnkfelix
Fix too restrictive checks on Drop impls
Fixes #34426. Fixes #58311.
This PR completes and extends #59497 (which has been inactive for a while now).
The problem generating both issues was that when checking that the `Predicate`s of the `Drop` impl are exactly the same as the ones of the struct definition, the check was essentially performed by a simple `==` operator, which was not handling correctly HRTBs and involved `Fn` types.
The implemented solution relies on the `relate` machinery to more correctly equate `Predicate`s, and on `anonymize_late_bound_regions` to handle HRTB in a more general way. As the `Relate` trait currently is implemented only for `TraitPredicate` and `ProjectionPredicate` (and as they were the ones generating problems), `relate` is used only for them while for other `Predicate`s the equality check is kept. I'm currently considering whether it would make sense to implement the `Relate` trait also for all other `Predicate`s to render the proposed solution more general.
Matthew Jasper [Sun, 8 Dec 2019 17:22:35 +0000 (17:22 +0000)]
Update tests for GATs
* Make some run-pass or check-pass
* Use `#![allow(incomplete_features)]`
* Update FIXMEs now that some of the issues have been addressed
* Add regression tests
bors [Sat, 21 Dec 2019 11:05:03 +0000 (11:05 +0000)]
Auto merge of #66994 - Centril:stmt-polish, r=estebank
refactor expr & stmt parsing + improve recovery
Summary of important changes (best read commit-by-commit, ignoring whitespace changes):
- `AttrVec` is introduces as an alias for `ThinVec<Attribute>`
- `parse_expr_bottom` and `parse_stmt` are thoroughly refactored.
- Extract diagnostics logic for `vec![...]` in a pattern context.
- Recovery is added for `do catch { ... }`
- Recovery is added for `'label: non_block_expr`
- Recovery is added for `var $local`, `auto $local`, and `mut $local`. Fixes #65257.
- Recovery is added for `e1 and e2` and `e1 or e2`.
- ~~`macro_legacy_warnings` is turned into an error (has been a warning for 3 years!)~~
- Fixes #63396 by forward-porting #64105 which now works thanks to added recovery.
- `ui-fulldeps/ast_stmt_expr_attr.rs` is turned into UI and pretty tests.
- Recovery is fixed for `#[attr] if expr {}`
bors [Sat, 21 Dec 2019 01:02:54 +0000 (01:02 +0000)]
Auto merge of #67464 - Centril:rollup-j3mkl1m, r=Centril
Rollup of 6 pull requests
Successful merges:
- #67130 (Const prop should finish propagation into user defined variables)
- #67163 (Split up ptr/mod.rs in libcore...)
- #67314 (Don't suppress move errors for union fields)
- #67392 (Fix unresolved type span inside async object)
- #67404 (Separate region inference logic from error handling better)
- #67428 (`is_binding_pat`: use explicit match & include or-pats in grammar)
Josh Stone [Fri, 20 Dec 2019 23:45:03 +0000 (15:45 -0800)]
Remove rustc-dev from the default nightly components
It was already filtered from other branches, but we only kept it in
nightly's default to ease the transition. Now that the separation of
rust-std/rustc-dev has reached the 1.40 release, it seems like a good
time for that transition to end.
Rollup merge of #67392 - csmoe:async-typeinfo, r=estebank
Fix unresolved type span inside async object
Closes #65180
r? @estebank
It's hard to create a minimal repro for that issue, [decided](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/meeting.202019.2E12.2E17/near/183675659) to give up finding mcve.
cc [previous take](https://github.com/rust-lang/rust/pull/65668)
Rollup merge of #67163 - TheSamsa:split-up-ptr-mod, r=Mark-Simulacrum
Split up ptr/mod.rs in libcore...
...one with implementation detail for const ptr and the other with mut ptr
I am not sure if the "stable since 1.0.0" flags are the correct choice for the two additional mods.
Also, is it necessary for them to be "pub"? If so, there should be a good description for them.
bors [Fri, 20 Dec 2019 20:56:09 +0000 (20:56 +0000)]
Auto merge of #67020 - pnkfelix:issue-59535-accumulate-past-lto-imports, r=mw
save LTO import info and check it when trying to reuse build products
Fix #59535
Previous runs of LTO optimization on the previous incremental build can import larger portions of the dependence graph into a codegen unit than the current compilation run is choosing to import. We need to take that into account when we choose to reuse PostLTO-optimization object files from previous compiler invocations.
This PR accomplishes that by serializing the LTO import information on each incremental build. We load up the previous LTO import data as well as the current LTO import data. Then as we decide whether to reuse previous PostLTO objects or redo LTO optimization, we check whether the LTO import data matches. After we finish with this decision process for every object, we write the LTO import data back to disk.
----
What is the scenario where comparing against past LTO import information is necessary?
I've tried to capture it in the comments in the regression test, but here's yet another attempt from me to summarize the situation:
1. Consider a call-graph like `[A] -> [B -> D] <- [C]` (where the letters are functions and the modules are enclosed in `[]`)
2. In our specific instance, the earlier compilations were inlining the call to`B` into `A`; thus `A` ended up with a external reference to the symbol `D` in its object code, to be resolved at subsequent link time. The LTO import information provided by LLVM for those runs reflected that information: it explicitly says during those runs, `B` definition and `D` declaration were imported into `[A]`.
3. The change between incremental builds was that the call `D <- C` was removed.
4. That change, coupled with other decisions within `rustc`, made the compiler decide to make `D` an internal symbol (since it was no longer accessed from other codegen units, this makes sense locally). And then the definition of `D` was inlined into `B` and `D` itself was eliminated entirely.
5. The current LTO import information reported that `B` alone is imported into `[A]` for the *current compilation*. So when the Rust compiler surveyed the dependence graph, it determined that nothing `[A]` imports changed since the last build (and `[A]` itself has not changed either), so it chooses to reuse the object code generated during the previous compilation.
6. But that previous object code has an unresolved reference to `D`, and that causes a link time failure!
----
The interesting thing is that its quite hard to actually observe the above scenario arising, which is probably why no one has noticed this bug in the year or so since incremental LTO support landed (PR #53673).
I've literally spent days trying to observe the bug on my local machine, but haven't managed to find the magic combination of factors to get LLVM and `rustc` to do just the right set of the inlining and `internal`-reclassification choices that cause this particular problem to arise.
----
Also, I have tried to be careful about injecting new bugs with this PR. Specifically, I was/am worried that we could get into a scenario where overwriting the current LTO import data with past LTO import data would cause us to "forget" a current import. ~~To guard against this, the PR as currently written always asserts, at overwrite time, that the past LTO import-set is a *superset* of the current LTO import-set. This way, the overwriting process should always be safe to run.~~
* The previous note was written based on the first version of this PR. It has since been revised to use a simpler strategy, where we never attempt to merge the past LTO import information into the current one. We just *compare* them, and act accordingly.
* Also, as you can see from the comments on the PR itself, I was quite right to be worried about forgetting past imports; that scenario was observable via a trivial transformation of the regression test I had devised.
bors [Fri, 20 Dec 2019 16:24:12 +0000 (16:24 +0000)]
Auto merge of #67455 - Centril:rollup-mf0yc81, r=Centril
Rollup of 5 pull requests
Successful merges:
- #64588 (Add a raw "address of" operator)
- #67031 (Update tokio crates to latest versions)
- #67131 (Merge `TraitItem` & `ImplItem into `AssocItem`)
- #67354 (Fix pointing at arg when cause is outside of call)
- #67363 (Fix handling of wasm import modules and names)
Rollup merge of #67363 - alexcrichton:wasm-import-modules, r=eddyb
Fix handling of wasm import modules and names
The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:
* If, in the same codegen unit, the same FFI symbol is referenced twice
then rustc, when translating to LLVM IR, will only reference one
symbol from the first wasm module referenced.
* There's also a bug in LLD [1] where even if two codegen units
reference different modules, having the same symbol names means that
LLD coalesces the symbols and only refers to one wasm module.
Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:
1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
mangled by default in LLVM IR. This means they're all given unique names.
2. Symbols then use the `wasm-import-name` attribute to ensure that the
WebAssembly file uses the correct import name.
When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.
Rollup merge of #67031 - mati865:tokio-update, r=nikomatsakis
Update tokio crates to latest versions
Drops few old crates from the workspace (they are only used during tests, not in Rust itself) and allows to remove even more crates during next `rustc-ap-*` update.
Rollup merge of #64588 - matthewjasper:mir-address-of, r=oli-obk
Add a raw "address of" operator
* Parse and feature gate `&raw [const | mut] expr` (feature gate name is `raw_address_of`)
* Add `mir::Rvalue::AddressOf`
* Use the new `Rvalue` for:
* the new syntax
* reference to pointer casts
* drop shims for slices and arrays
* Stop using `mir::Rvalue::Cast` with a reference as the operand
* Correctly evaluate `mir::Rvalue::{Ref, AddressOf}` in constant propagation