Auto merge of #53693 - scottmcm:marker-trait-attribute, r=nikomatsakis
Support an explicit annotation for marker traits
From the tracking issue for rust-lang/rfcs#1268:
> It seems obvious that we should make a `#[marker]` annotation. ~ https://github.com/rust-lang/rust/issues/29864#issuecomment-368959441
This PR allows you to put `#[marker]` on a trait, at which point:
- [x] The trait must not have any items ~~All of the trait's items must have defaults~~
- [x] Any impl of the trait must be empty (not override any items)
- [x] But impls of the trait are allowed to overlap
Auto merge of #53438 - matthewjasper:permissive-match-access, r=pnkfelix
[NLL] Be more permissive when checking access due to Match
Partially addresses #53114. notably, we should now have parity with AST borrowck. Matching on uninitialized values is still forbidden.
* ~~Give fake borrows for match their own `BorrowKind`~~
* ~~Allow borrows with this kind to happen on values that are already mutably borrowed.~~
* ~~Track borrows with this type even behind shared reference dereferences and consider all accesses to be deep when checking for conflicts with this borrow type. See [src/test/ui/issues/issue-27282-mutate-before-diverging-arm-3.rs](https://github.com/rust-lang/rust/commit/cb5c989598178af505fb215dd97afca8cc2b659f#diff-a2126cd3263a1f5342e2ecd5e699fbc6) for an example soundness issue this fixes (a case of #27282 that wasn't handled correctly).~~
* Create a new `BorrowKind`: `Shallow` (name can be bike-shed)
* `Shallow` borrows differ from shared borrows in that
* When we check for access we treat them as a `Shallow(Some(_))` read
* When we check for conflicts with them, if the borrow place is a strict prefix of the access place then we don't consider that a conflict.
* For example, a `Shallow` borrow of `x` does not conflict with any access or borrow of `x.0` or `*x`
* Remove the current fake borrow in matches.
* When building matches, we take a `Shallow` borrow of any `Place` that we switch on or bind in a match, and any prefix of those places. (There are some optimizations where we do fewer borrows, but this shouldn't change semantics)
* `match x { &Some(1) => (), _ => (), }` would `Shallow` borrow `x`, `*x` and `(*x as Some).0` (the `*x` borrow is unnecessary, but I'm not sure how easy it would be to remove.)
* Replace the fake discriminant read with a `ReadForMatch`.
* Change ReadForMatch to only check for initializedness (to prevent `let x: !; match x {}`), but not conflicting borrows. It is still considered a use for liveness and `unsafe` checking.
* Give special cased error messages for this kind of borrow.
Auto merge of #53783 - RalfJung:ptr-docs, r=alexcrichton
Rewrite docs for pointer methods
This takes over https://github.com/rust-lang/rust/pull/51016 by @ecstatic-morse. They did most of the work, I just did some editing.
However, I realized one problem: This updates the docs for the "free functions" in `core::ptr`, but it does not update the copies of these docs for the inherent methods of the `*const T` and `*mut T` types. These getting out-of-sync is certainly bad, but I also don't feel like copying all this stuff around. Instead, we should remove this redundancy. Any good ideas?
Auto merge of #54509 - matthewjasper:better-drop-access, r=pnkfelix
[NLL] Rework checking for borrows conflicting with drops
Previously, we would split the drop access into multiple checks for each
field of a struct/tuple/closure and through `Box` dereferences. This
changes this to check if the borrow is accessed by the drop in
`places_conflict`.
Auto merge of #54485 - arielb1:avoid-ctor-attrs, r=eddyb
avoid loading constructor attributes in AdtDef decoding
During metadata loading, the AdtDefs for every ADT in the universe need
to be loaded (for example, for coherence of builtin traits). For that,
the attributes of the AdtDef need to be loaded too.
The attributes of a struct are duplicated between 2 def ids - the
constructor def-id, and the "type" def id. Loading attributes for both
def-ids, which was done in #53721, slowed the compilation of small
crates by 2-3%. This PR makes sure we only load the attributes for the
"type" def-id, avoiding the slowdown.
Matthew Jasper [Sun, 23 Sep 2018 15:07:45 +0000 (16:07 +0100)]
Rework checking for borrows conflicting with drops
Previously, we would split the drop access into multiple checks for each
field of a struct/tuple/closure and through `Box` dereferences. This
changes this to check if the borrow is accessed by the drop in
places_conflict.
This also allows us to handle enums in a simpler way, since we don't
have to construct any new places.
Matthew Jasper [Sun, 23 Sep 2018 14:56:14 +0000 (15:56 +0100)]
Remove irrelevant message about drop order
When dropping a self-borrowing struct we shouldn't add a "values in a
scope are dropped in the opposite order they are defined" message,
since there is only one value being dropped.
David Wood [Wed, 19 Sep 2018 00:48:47 +0000 (02:48 +0200)]
Only annotate if borrow is returned.
Error now correctly checks whether the borrow that does not live
long enough is being returned before annotating the error with the
arguments and return type from the signature - as this would not be
relevant if the borrow was not being returned.
David Wood [Mon, 17 Sep 2018 18:49:21 +0000 (20:49 +0200)]
Added note about dangling references.
This error can only occur within a function when a borrow of data owned
within the function is returned; and when there are arguments that could
have been returned instead. Therefore, it is always applicable to add a
specific note that links to the relevant rust documentation about
dangling references.
David Wood [Tue, 11 Sep 2018 15:57:58 +0000 (17:57 +0200)]
Improve non-closure, reference in-and-out errors.
For cases where there are references in the parameters and in the the
outputs that do not match, and where no closures are involved, this
commit introduces an improved error that mentions (or synthesizes)
a name for the regions involved to better illustrate why the borrow
does not live long enough.
David Wood [Tue, 11 Sep 2018 11:27:39 +0000 (13:27 +0200)]
Refactor region naming for control of diagnostics.
Previously, region naming would always highlight the source of the
region name it found. Now, region naming returns the name as part
of a larger structure that encodes the source of the region naming
such that a region name can be optionally added to the diagnostic.
David Wood [Sun, 9 Sep 2018 17:34:39 +0000 (19:34 +0200)]
Refactor explain_borrow to return explanation.
Previously, explain_borrow would emit an error with the explanation of
the a borrow. Now, it returns a enum with what the explanation for the
borrow is and any relevant spans or information such that the calling
code can choose to emit the same note/suggestion as before by calling
the emit method on the new enum.
Auto merge of #54325 - michaelwoerister:incr-thinlto-tests, r=alexcrichton
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO.
This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way.
I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo.
Auto merge of #54310 - pnkfelix:issue-52059-report-borrow-drop-conflict, r=nikomatsakis
Report when borrow could cause `&mut` aliasing during Drop
We were already issuing an error for the cases where this cropped up, so this is not fixing any soundness holes. The previous diagnostic just wasn't accurately describing the problem in the user's code.
Auto merge of #54262 - matthewjasper:explain-in-typeck, r=nikomatsakis
[NLL] Record more infomation on free region constraints in typeck
Changes:
* Makes the span of the MIR return place point to the return type
* Don't try to use a path to a type alias as a path to the adt it aliases (fixes an ICE)
* Don't claim that `self` is declared outside of the function. [see this test](https://github.com/rust-lang/rust/commit/f2995d5b1ad0401a80ac4579ebc89295818c3eed#diff-0c9e6b1b204f42129b481df9ce459d44)
* Remove boring/interesting distinction and instead add a `ConstraintCategory` to the constraint.
* Add categories for implicit `Sized` and `Copy` requirements, for closure bounds, for user type annotations and `impl Trait`.
* Don't use the span of the first statement for Locations::All bounds (even if it happens to work on the tests we have)
Future work:
* Fine tuning the heuristic used to choose the place the report the error.
* Reporting multiple places (behind a flag)
* Better closure bounds reporting. This probably requires some discussion.
Auto merge of #53508 - japaric:maybe-uninit, r=RalfJung
Implement `MaybeUninit`
This PR:
- Adds `MaybeUninit` (see #53491) to `{core,std}::mem`.
- Makes `mem::{uninitialized,zeroed}` panic when they are used to instantiate an uninhabited type.
- Does *not* deprecate `mem::{uninitialized,zeroed}` just yet. As per https://github.com/rust-lang/rust/issues/53491#issuecomment-414147666, we should not deprecate them until `MaybeUninit` is stabilized.
- It replaces uses of `mem::{uninitialized,zeroed}` in core and alloc with `MaybeUninit`.
There are still several instances of `mem::{uninitialized,zeroed}` in `std` that *this* PR doesn't address.
r? @RalfJung
cc @eddyb you may want to look at the new panicking logic
avoid loading constructor attributes in AdtDef decoding
During metadata loading, the AdtDefs for every ADT in the universe need
to be loaded (for example, for coherence of builtin traits). For that,
the attributes of the AdtDef need to be loaded too.
The attributes of a struct are duplicated between 2 def ids - the
constructor def-id, and the "type" def id. Loading attributes for both
def-ids, which was done in #53721, slowed the compilation of small
crates by 2-3%. This PR makes sure we only load the attributes for the
"type" def-id, avoiding the slowdown.
Auto merge of #54457 - pietroalbini:rollup, r=pietroalbini
Rollup of 16 pull requests
Successful merges:
- #53652 (define copy_within on slices)
- #54261 (Make `dyn` a keyword in the 2018 edition)
- #54280 (remove (more) CAS API from Atomic* types where not natively supported)
- #54323 (rustbuild: drop color handling)
- #54350 (Support specifying edition in doc test)
- #54370 (Improve handling of type bounds in `bit_set.rs`.)
- #54371 (add -Zui-testing to rustdoc)
- #54374 (Make 'proc_macro::MultiSpan' public.)
- #54402 (Use no_default_libraries for all NetBSD flavors)
- #54409 (Detect `for _ in in bar {}` typo)
- #54412 (add applicability to span_suggestion call)
- #54413 (Add UI test for deref recursion limit printing twice)
- #54415 (parser: Tweak function parameter parsing to avoid rollback on succesfull path)
- #54420 (Compress `Liveness` data some more.)
- #54422 (Simplify slice's first(_mut) and last(_mut) with get)
- #54446 (Unify christianpoveda's emails)
Failed merges:
- #54058 (Introduce the partition_dedup/by/by_key methods for slices)
Auto merge of #54265 - arielb1:civilize-proc-macros, r=alexcrichton
avoid leaking host details in proc macro metadata decoding
proc macro crates are essentially implemented as dynamic libraries using
a dlopen-based ABI. They are also Rust crates, so they have 2 worlds -
the "host" world in which they are defined, and the "target" world in
which they are used.
For all the "target" world knows, the proc macro crate might not even
be implemented in Rust, so leaks of details from the host to the target
must be avoided for correctness.
Because the "host" DefId space is different from the "target" DefId
space, any leak involving a DefId will have a nonsensical or
out-of-bounds DefKey, and will cause all sorts of crashes.
This PR fixes all leaks I have found in `decoder`. In particular, #54059
was caused by host native libraries leaking into the target, which feels
like it might even be a correctness issue if it doesn't cause an ICE.
Pietro Albini [Sat, 22 Sep 2018 07:56:41 +0000 (09:56 +0200)]
Rollup merge of #54420 - nnethercote:PackedRWU-Vec, r=nikomatsakis
Compress `Liveness` data some more.
Profiling shows that the `(reader, writer, used)` triples used by
liveness analysis almost always have invalid `reader` and `writer`
fields. We can take advantage of this knowledge to use a compressed
representation for them, falling back to a secondary table for the
uncommon cases.
This change reduces instruction counts on numerous benchmarks, the best
by 16%. It also reduces max-rss on numerous benchmarks, the best by 38%.
The patch also renames these triples from `Users` to `RWU`, because it's
confusing having a type whose name is plural and then used within
vectors whose names are also plural.
Pietro Albini [Sat, 22 Sep 2018 07:56:40 +0000 (09:56 +0200)]
Rollup merge of #54415 - petrochenkov:norollback, r=estebank
parser: Tweak function parameter parsing to avoid rollback on succesfull path
Since rollback is not perfect and may e.g. leave non-fatal errors after it, we need to make sure compilation fails if it happens.
So in particular case of `fn parse_arg_general` we need to parse the "good" `TYPE` first and only then rollback and recover erroneous `PAT: TYPE` if necessary.
Found when working on https://github.com/rust-lang/rfcs/pull/2544#issuecomment-423293222.
Pietro Albini [Sat, 22 Sep 2018 07:56:39 +0000 (09:56 +0200)]
Rollup merge of #54413 - memoryruins:deref-error-twice, r=estebank
Add UI test for deref recursion limit printing twice
Closes #38940
Does ``NOTE`` in the test need to be changed to ``HELP`` if its in the stderr?
``help: consider adding a `#![recursion_limit="20"]` attribute to your crate``
It doesn't appear to complaining locally that the line isn't set to ``HELP`` in the test, and the guide says
> HELP and SUGGESTION*
> * Note: SUGGESTION must follow immediately after HELP.
Pietro Albini [Sat, 22 Sep 2018 07:56:35 +0000 (09:56 +0200)]
Rollup merge of #54402 - bgermann:master, r=alexcrichton
Use no_default_libraries for all NetBSD flavors
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close #49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
Pietro Albini [Sat, 22 Sep 2018 07:56:28 +0000 (09:56 +0200)]
Rollup merge of #54280 - japaric:no-cas-for-thumbv6, r=alexcrichton
remove (more) CAS API from Atomic* types where not natively supported
closes #54276
In PR #51953 I made the Atomic* types available on targets like thumbv6m and
msp430 with the intention of *only* exposing the load and store API on those
types -- the rest of the API doesn't work on those targets because the are no
native instructions to implement CAS loops.
Unfortunately, it seems I didn't properly cfg away all the CAS API on those
targets, as evidenced in #54276. This PR amends the issue by removing the rest
of the CAS API.
This is technically a breaking change because *libraries* that were using this
API and were being compiled for e.g. thumbv6m-none-eabi will stop compiling.
However, using those libraries (before this change) in programs (binaries) would
lead to linking errors when compiled for e.g. thumbv6m so this change
effectively shifts a linker error in binaries to a compiler error in libraries.
On a side note: extending the Atomic API is a bit error prone because of these
non-cas targets. Unless the author of the change is aware of these targets and
properly uses `#[cfg(atomic = "cas")]` they could end up exposing new CAS API on
these targets. I can't think of a test to check that an API is not present on
some target, but we could extend the `tidy` tool to check that *all* newly added
atomic API has the `#[cfg(atomic = "cas")]` attribute unless it's whitelisted in
`tidy` then the author of the change would have to verify if the API can be used
on non-cas targets.
In any case, I'd like to plug this hole ASAP. We can revisit testing in a
follow-up issue / PR.
Pietro Albini [Sat, 22 Sep 2018 07:56:24 +0000 (09:56 +0200)]
Rollup merge of #53652 - oconnor663:copy_in_place, r=alexcrichton
define copy_within on slices
This is a safe wrapper around `ptr::copy`, for regions within a single slice. Previously, safe in-place copying was only available as a side effect of `Vec::drain`.
I've wanted this API a couple times in the past, and I figured I'd just whip up a PR to help discuss it. It's possible something like this exists elsewhere and I just missed it. It might also be a big enough addition to warrant an RFC, I'm not sure.
Auto merge of #54223 - pnkfelix:issue-53764-uiify-run-pass, r=nikomatsakis
`ui`ify run-pass
This addresses the remainder of #53764 by first converting `src/test/run-pass` into another `ui`-style test suite, and then turning on `compare-mode=nll` for that new suite.
After this lands, we can address #54047 for the short term by moving all the `src/test/ui/run-pass` tests back to `src/test/run-pass`.
(Longer term, the compiler team's current (hypothetical sketch of a) plan (see [1][], [2][]) is unify all the tests by embedding these meta-properties like "// run-pass` into their headers explicitly and dropping the significance of their location on the file system.)
Alex Crichton [Thu, 20 Sep 2018 21:37:53 +0000 (14:37 -0700)]
Update Cargo
This commit brings in a few Cargo updates
* Updates Cargo with experimental HTTP/2 support - a post on the forums
will be made about testing this when available.
* Bumps Cargo's own version number
projects / rust.git / log