Rollup merge of #70289 - nnethercote:refactor-codegen, r=eddyb
Refactor `codegen`
`codegen` in `src/librustc_codegen_llvm/back/write.rs` is long and has complex control flow. These commits refactor it and make it easier to understand.
Rollup merge of #70213 - eddyb:stalled-on-ty-or-const, r=nikomatsakis
traits/fulfill: allow `stalled_on` to track `ty::Const::Infer(_)` (unused yet).
This PR addresses the representation side of #70180, but only *actually collects* `ty::Infer`s via `Ty::walk` into `stalled_on` (collecting `ty::ConstKind::Infer`s requires #70164).
However, it should be enough to handle #70107's needs (WF obligations are stalled only on the outermost type/const being an inference variable, no `walk`-ing is involved).
This is my second attempt, see #70181 for the previous one, which unacceptably regressed perf.
Rollup merge of #70077 - Aaron1011:feature/new-def-path-ident, r=petrochenkov
Store idents for `DefPathData` into crate metadata
Previously, we threw away the `Span` associated with a definition's
identifier when we encoded crate metadata, causing us to lose location
and hygiene information.
We now store the identifier's `Span` in a side table, which gets encoded
into the crate metadata. When we decode items from the metadata, we
combine the name and span back into an `Ident`.
This improves the output of several tests, which previously had messages
suppressed due to dummy spans.
This is a prerequisite for #68686, since throwing away a `Span` means
that we lose hygiene information.
bors [Tue, 24 Mar 2020 00:53:25 +0000 (00:53 +0000)]
Auto merge of #70343 - Centril:rollup-94egfvs, r=Centril
Rollup of 11 pull requests
Successful merges:
- #67761 (Move the dep_graph construction to a dedicated crate.)
- #69740 (Replace some desc logic in librustc_lint with article_and_desc)
- #69981 (Evaluate repeat expression lengths as late as possible)
- #70087 (Remove const eval loop detector)
- #70242 (Improve E0308 error message wording)
- #70264 (Fix invalid suggestion on `&mut` iterators yielding `&` references)
- #70267 (get rid of ConstPropUnsupported; use ZST marker structs instead)
- #70277 (Remove `ReClosureBound`)
- #70283 (Add regression test for #70155.)
- #70294 (Account for bad placeholder types in where clauses)
- #70309 (Clean up E0452 explanation)
Rollup merge of #70283 - CDirkx:regression-test-70155, r=oli-obk
Add regression test for #70155.
With #70166 merged, `RangeInclusive` now derives `PartialEq` and `Eq`, implementing structural equality and as a side effect the range is now usable with const generics, closing #70155.
As per [#70166 (comment)](https://github.com/rust-lang/rust/pull/70166#issuecomment-601872201) a test is added to avoid a change to the private fields or the equality implementation of the range from subtly reverting #70155.
Rollup merge of #70264 - tirr-c:issue-69789-mut-suggestion, r=estebank
Fix invalid suggestion on `&mut` iterators yielding `&` references
Fixes #69789.
rustc suggested an invalid code when `&` reference from `&mut` iterator is mutated. The compiler knew we're mutating a value behind `&` reference, but as the assignment RHS is from desugaring, it could only see the iterator expression from source and inserted `mut` there.
Rollup merge of #70242 - DeeDeeG:improve-e0308, r=Dylan-DPC
Improve E0308 error message wording
Hi folks,
I made [a post on Reddit](https://old.reddit.com/r/rust/comments/fmi11x/consider_linting_rusts_documentationerror_text/) about how (IMO) the docs/error messages can be a bit intimidating, one thing led to another, and I was encouraged to submit a Pull Request if I felt I could re-phrase the error message that I used as an example.
So that's this Pull Request. Open to any feedback or style changes, and I understand this is subjective.
(On another note: I am happy to see [this message was recently improved](https://github.com/rust-lang/rust/pull/69139) in `master`, so it's already better than it is in stable Rust 1.42.0.)
Ideally the last sentence could be split into at least two: [sentence explaining the inferred type.] [Sentence explaining explicit type.] [Sentence that summarizes that "this is bad," and why.]
But I'm not sure how to do so; I'm wary of writing something that turns out to be technically incorrect.
Rollup merge of #70087 - ecstatic-morse:remove-const-eval-loop-detector, r=RalfJung
Remove const eval loop detector
Now that there is a configurable instruction limit for CTFE (see #67260), we can replace the loop detector with something much simpler. See #66946 for more discussion about this. Although the instruction limit is nightly-only, the only practical way to reach the default limit uses nightly-only features as well (although CTFE will still execute code using such features inside an array initializer on stable).
This will at the very least require a crater run, since it will result in an error wherever the "long running const eval" warning appeared before. We may need to increase the default for `const_eval_limit` to work around this.
Resolves #54384 cc #49980
r? @oli-obk cc @RalfJung
Rollup merge of #67761 - cjgillot:split_graph, r=Zoxc
Move the dep_graph construction to a dedicated crate.
The interface for librustc consists in two traits: `DepKind` and `DepContext`.
The `DepKind` is the main interface. It allows to probe properties of the dependency.
As before, `DepNode` is the pair of a `DepKind` object and a hash fingerprint.
The `DepContext` takes the place of the `TyCtxt`, and handles communication with the query engine.
The use of the `ImplicitCtxt` through `ty::tls` is done through the `DepKind` trait.
This may not be the best choice, but it seemed like the simplest.
Changes:
````
rustup https://github.com/rust-lang/rust/pull/69968/
Fix documentation generation for configurable lints
Fix single binding in closure
Improvement: Don't show function body in needless_lifetimes
````
Fixes #70310
r? @Dylan-DPC
bors [Mon, 23 Mar 2020 18:48:02 +0000 (18:48 +0000)]
Auto merge of #70330 - Centril:rollup-ts0clvx, r=Centril
Rollup of 9 pull requests
Successful merges:
- #68700 (Add Wake trait for safe construction of Wakers.)
- #69494 (Stabilize --crate-version option in rustdoc)
- #70080 (rustc_mir: remove extra space when pretty-printing MIR.)
- #70195 (Add test for issue #53275)
- #70199 (Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.)
- #70299 (add err_machine_stop macro)
- #70300 (Reword unused variable warning)
- #70315 (Rename remaining occurences of Void to Opaque.)
- #70318 (Split long derive lists into two derive attributes.)
The test are moved from `test\ui\const-generics\issues\issue-70155` to `test\ui\const-generics\std\range` in anticipation of future similar tests for std types.
Rollup merge of #68700 - withoutboats:wake-trait, r=withoutboats
Add Wake trait for safe construction of Wakers.
Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`.
Therefore, the Wake trait was left out of the initial version of the task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
Changes:
````
rustup https://github.com/rust-lang/rust/pull/69968/
Fix documentation generation for configurable lints
Fix single binding in closure
Improvement: Don't show function body in needless_lifetimes
````
Without Boats [Fri, 31 Jan 2020 13:26:24 +0000 (14:26 +0100)]
Add Wake trait for safe construction of Wakers.
Currently, constructing a waker requires calling the unsafe
`Waker::from_raw` API. This API requires the user to manually construct
a vtable for the waker themself - which is both cumbersome and very
error prone. This API would provide an ergonomic, straightforward and
guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially
function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two
considerations prevented the original API from being shipped as simply
an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an
allocator, and in optimized executors for which this API may not be
best-suited. Therefore, we have always explicitly supported the
maximally-flexible (but also memory-unsafe) `RawWaker` API, and
`Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has
not been feasible to provide a constructor for `Waker` from `Arc<dyn
Wake>`.
Therefore, the Wake trait was left out of the initial version of the
task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan
rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc.
Therefore, we can now define this constructor even though `Waker` lives
in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by
`Waker::wake_by_ref` and which implementors can override if they
can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send +
Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
bors [Mon, 23 Mar 2020 12:40:36 +0000 (12:40 +0000)]
Auto merge of #69649 - estebank:negative-impl-span, r=Centril
Tweak output for invalid negative impl errors
Follow up to #69722. Tweak negative impl errors emitted in the HIR:
```
error[E0192]: invalid negative impl
--> $DIR/E0192.rs:9:6
|
LL | impl !Trait for Foo { }
| ^^^^^^
|
= note: negative impls are only allowed for auto traits, like `Send` and `Sync`
```
bors [Mon, 23 Mar 2020 09:30:00 +0000 (09:30 +0000)]
Auto merge of #70305 - Centril:rollup-zi13fz4, r=Centril
Rollup of 8 pull requests
Successful merges:
- #69080 (rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.)
- #69940 (librustc_codegen_llvm: Replace deprecated API usage)
- #69942 (Increase verbosity when suggesting subtle code changes)
- #69968 (rustc: keep upvars tupled in {Closure,Generator}Substs.)
- #70123 (Ensure LLVM is in the link path for rustc tools)
- #70159 (Update the bundled wasi-libc with libstd)
- #70233 (resolve: Do not resolve visibilities on proc macro definitions twice)
- #70286 (Miri error type: remove UbExperimental variant)
Rollup merge of #70123 - cuviper:library-path, r=Mark-Simulacrum
Ensure LLVM is in the link path for rustc tools
The build script for `rustc_llvm` outputs LLVM information in `cargo:rustc-link-lib` and `cargo:rustc-link-search` so the compiler can be linked correctly. However, while the lib is carried along in metadata, the search paths are not. So when cargo is invoked again later for rustc _tools_, they'll also try to link with LLVM, but the necessary paths may be left out.
Rustbuild can use the environment to set the LLVM link path for tools -- `LIB` for MSVC toolchains and `LIBRARY_PATH` for everyone else.
Rollup merge of #69968 - eddyb:tupled-closure-captures, r=nikomatsakis
rustc: keep upvars tupled in {Closure,Generator}Substs.
Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`.
Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods.
To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are:
* before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]`
* after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]`
You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types.
projects / rust.git / log