Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 9 pull requests #73313

Closed
wants to merge 45 commits into from
Closed

Conversation

RalfJung
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

Aaron1011 and others added 30 commits May 25, 2020 23:18
Fixes rust-lang#69446

When we encounter a region error involving an `FnMut` closure, we
display a specialized error message. However, we currently do not
tell the user which upvar was captured. This makes it difficult to
determine the cause of the error, especially when the closure is large.

This commit records marks constraints involving closure upvars
with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame'
a `ConstraintCategory::Return`, we additionall store
the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in
the path.

When generating an error message, we point to relevant spans if we have
closure upvar information available. We further customize the message if
an `async` closure is being returned, to make it clear that the captured
variable is being returned indirectly.
Also, implement this query for the local crate, not just foreign crates.
yerke and others added 10 commits June 13, 2020 00:41
… r=nikomatsakis

Explain move errors that occur due to method calls involving `self`

When calling a method that takes `self` (e.g. `vec.into_iter()`), the method receiver is moved out of. If the method receiver is used again, a move error will be emitted::

```rust
fn main() {
    let a = vec![true];
    a.into_iter();
    a;
}
```

emits

```
error[E0382]: use of moved value: `a`
 --> src/main.rs:4:5
  |
2 |     let a = vec![true];
  |         - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 |     a.into_iter();
  |     - value moved here
4 |     a;
  |     ^ value used here after move
```

However, the error message doesn't make it clear that the move is caused by the call to `into_iter`.

This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method::

```
error[E0382]: use of moved value: `a`
   --> vec.rs:4:5
    |
2   |     let a = vec![true];
    |         - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3   |     a.into_iter();
    |     ------------- value moved due to this method call
4   |     a;
    |     ^ value used here after move
    |
note: this function takes `self`, which moves the receiver
   --> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5
    |
239 |     fn into_iter(self) -> Self::IntoIter;
```

TODO:

- [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods
- [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`)
- [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.
…n, r=nikomatsakis

Display information about captured variable in `FnMut` error

Fixes rust-lang#69446

When we encounter a region error involving an `FnMut` closure, we
display a specialized error message. However, we currently do not
tell the user which upvar was captured. This makes it difficult to
determine the cause of the error, especially when the closure is large.

This commit records marks constraints involving closure upvars
with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame'
a `ConstraintCategory::Return`, we additionall store
the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in
the path.

When generating an error message, we point to relevant spans if we have
closure upvar information available. We further customize the message if
an `async` closure is being returned, to make it clear that the captured
variable is being returned indirectly.
…, r=nikomatsakis

Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position

* Suggest substituting `'static` lifetime in impl/dyn `Trait + 'static` instead of `Trait + 'static + '_`
* When `'static` is explicit, also suggest constraining argument with it
* Reduce verbosity of suggestion message and mention lifetime in label
* Tweak output for overlapping required/captured spans
* Give these errors an error code

Follow up to rust-lang#72543.

r? @nikomatsakis
…iour, r=hanna-kruppe

Clarify the behaviour of Pattern when used with methods like str::contains

Fixes rust-lang#45507.

I used the previous work by @Emerentius (thanks !), added a paragraph and checked the links (they work for me but I'm not against someone else checking them too).
Upgrade Chalk

Things done in this PR:
- Upgrade Chalk to `0.11.0`
- Added compare-mode=chalk
- Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk
- Removed `RustDefId` since the builtin type support is there
- Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk
- Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`)
- Lower `RegionOutlives` and `ObjectSafe` predicates
- Lower `Dyn` without the region
- Handle `Int`/`Float` `CanonicalVarKind`s
- Uncomment some Chalk tests that actually work now
- Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different

r? @nikomatsakis
Rename "cyclone" to "apple-a7" per changes in upstream LLVM

It looks like they intended to keep "cyclone" as a legacy option, but removed it from the list of subtarget features. This created a flood of warnings when targeting aarch64-apple-ios, and probably also created incorrectly optimized artifacts.

See:
https://reviews.llvm.org/D70779
https://reviews.llvm.org/D70779#C1703593NL568

LLVM 10 merged into master at:
rust-lang#67759
…Simulacrum

Use the built cargo for cargotest.

cargotest was using the beta (bootstrap) cargo. This changes it so that it will use the locally built cargo. This is intended to provide a sort of smoke test to ensure Cargo is functional. This *shouldn't* have any real impact on the CI build time.  The cargotest job also happens to run cargo's testsuite, so it should already be building cargo.

Note: This will fail until rust-lang#73266 is merged.
Fix links when pinging notification groups

I think a blank line is necessary for the link to be applied.
Not sure who to assign, r? @Dylan-DPC
…rch64, r=Amanieu

pretty/asm.rs should only be tested for x86_64 and not AArch64

pretty/asm.rs should only be tested for x86_64 and not AArch64
closes rust-lang#73134
r?  @Amanieu
@RalfJung
Copy link
Member Author

@rustbot modify labels: +rollup
@bors r+ rollup=never p=9

@bors
Copy link
Contributor

bors commented Jun 13, 2020

📌 Commit 73d2c3e has been approved by RalfJung

@rustbot rustbot added the rollup A PR which is a rollup label Jun 13, 2020
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 13, 2020
@bors
Copy link
Contributor

bors commented Jun 13, 2020

⌛ Testing commit 73d2c3e with merge eb011eb851e4e66a70166683a4657ccfd4d366a0...

@bors
Copy link
Contributor

bors commented Jun 13, 2020

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 13, 2020
@RalfJung
Copy link
Member Author

OOM?

memory allocation of 268435456 bytes failed
error: Could not document `rustc_traits`.

Cc @rust-lang/infra is that something that happens occasionally?
@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 13, 2020
@bors
Copy link
Contributor

bors commented Jun 13, 2020

⌛ Testing commit 73d2c3e with merge 0b86853ab6fe3733383141de1b03fdc2fc932c53...

@tmiasko
Copy link
Contributor

tmiasko commented Jun 13, 2020

It doesn't seem completely spurious since it happened on both Azure and GHA within same pipeline / builder.

@RalfJung
Copy link
Member Author

Hm, good point. Let's try just the chalk PR then.
@bors retry r-

@RalfJung RalfJung closed this Jun 13, 2020
@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 13, 2020
@RalfJung RalfJung deleted the rollup-x99o1v1 branch June 13, 2020 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet