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 7 pull requests #89903

Merged
merged 15 commits into from
Oct 15, 2021
Merged

Rollup of 7 pull requests #89903

merged 15 commits into from
Oct 15, 2021

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tlyu and others added 15 commits October 7, 2021 20:24
In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.
The checking variant ensures that the offset required is not larger than
12 bits - hence we wouldn't ever need the upper 12 bits.
…stebank

move implicit `Sized` predicate to end of list

In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.

Fixes rust-lang#85998, at least partially. ~~Based on rust-lang#85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.

I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason.

I also ran into an instance of rust-lang#84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.

``@estebank`` this seems likely to conflict (slightly?) with your work on rust-lang#85947; how would you like to resolve that?
…ark-Simulacrum

Add a strange test for `unsafe_code` lint.

The current behavior is a little surprising to me. I'm not sure whether people would change it, but at least let me document the current behavior with a test.

I learnt about this from the [totally-speedy-transmute](https://docs.rs/totally-speedy-transmute) crate.

cc rust-lang#10599 the original implementation pr.
add dedicated error variant for writing the discriminant of an uninhabited enum variant

This is conceptually different from hitting an `Unreachable` terminator. Also add some sanity check making sure we don't write discriminants of things that do not have discriminants.

r? ``@oli-obk``
Suggest Box::pin when Pin::new is used instead

This fixes an incorrect diagnostic.

**Based on rust-lang#89390**; only the last commit is specific to this PR. "Ignore whitespace changes" also helps here.
…anieu

Use non-checking TLS relocation in aarch64 asm! sym test.

The checking variant ensures that the offset required is not larger than 12 bits - hence we wouldn't ever need the upper 12 bits.

It's unlikely to ever fail in this small test but this is technically correct.

This was noticed incidentally when we found that LLD doesn't support the `tprel_lo12` relocation, even though LLVM can apparently generate it when using `-mtls-size=12`.
… r=GuillaumeGomez

add long explanation for E0183

Addresses rust-lang#61137
…lacrum

Remove unused dependencies from rustc_const_eval
@rustbot rustbot added the rollup A PR which is a rollup label Oct 15, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ p=7 rollup=never

@bors
Copy link
Contributor

bors commented Oct 15, 2021

📌 Commit e45c222 has been approved by matthiaskrgr

@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 Oct 15, 2021
@bors
Copy link
Contributor

bors commented Oct 15, 2021

⌛ Testing commit e45c222 with merge 72d6606...

@bors
Copy link
Contributor

bors commented Oct 15, 2021

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 72d6606 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 15, 2021
@bors bors merged commit 72d6606 into rust-lang:master Oct 15, 2021
@rustbot rustbot added this to the 1.57.0 milestone Oct 15, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (72d6606): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@matthiaskrgr matthiaskrgr deleted the rollup-s0c69xl branch November 20, 2021 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.