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 8 pull requests #73299

Closed
wants to merge 27 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

Aaron1011 and others added 27 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.
Add needs-sanitizer-{address,leak,memory,thread} directive indicating
that test requires target with support for specific sanitizer.

This is an addition to the existing needs-sanitizer-support directive
indicating that test requires a sanitizer runtime library.
…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).
…akis

compiletest: Add directives to detect sanitizer support

Add needs-sanitizer-{address,leak,memory,thread} directive indicating
that test requires target with support for specific sanitizer.

This is an addition to the existing needs-sanitizer-support directive
indicating that test requires a sanitizer runtime library.

The existing needs-sanitizer-support directive could be incorporated into the
new ones, but I decided to retain it, since it enables running sanitizer
codegen tests even when building of sanitizer runtime libraries is disabled.
Fix link error with #[thread_local] introduced by rust-lang#71192

r? @oli-obk
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
@Dylan-DPC-zz
Copy link
Author

@bors r+ p=8 rollup=never

@bors
Copy link
Contributor

bors commented Jun 13, 2020

📌 Commit bba35b1 has been approved by Dylan-DPC

@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 bba35b1 with merge 4e266d215636c6f2e4318770972866dc4d78888f...

@RalfJung
Copy link
Member

CI already failed but bors did not notice yet, or what is happening...?

@RalfJung
Copy link
Member

Oh, the failing one is GHA, which we currently don't gate on. But let's assume the Azure runner will also fail.

@trevyn
Copy link
Contributor

trevyn commented Jun 13, 2020

Where is the failing GHA?

@RalfJung
Copy link
Member

@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. 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 13, 2020
@trevyn
Copy link
Contributor

trevyn commented Jun 13, 2020

Ah, a bunch of sanitizer stuff. #73044?

@RalfJung
Copy link
Member

Where do you see sanitizer stuff? #73065 was identified by @tmiasko and I agree with that.

@RalfJung
Copy link
Member

Oh there was a second one. But how did you get that from the link I posted?^^

@trevyn
Copy link
Contributor

trevyn commented Jun 13, 2020

Was from azure :)

@RalfJung
Copy link
Member

A link to the concrete log would have been very helpful. :)

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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.