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 #73206

Merged
merged 29 commits into from
Jun 11, 2020
Merged

Rollup of 9 pull requests #73206

merged 29 commits into from
Jun 11, 2020

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

spastorino and others added 29 commits May 28, 2020 16:09
Fixes rust-lang#72839

In PR rust-lang#72621, trait selection was modified to no longer bail out early
when an error type was encountered. This allowed us treat `ty::Error` as
`Sized`, causing us to avoid emitting a spurious "not sized" error after
a type error had already occured.

However, this means that we may now try to match an impl candidate
against the error type. Since the error type will unify with almost
anything, this can cause us to infinitely recurse (eventually triggering
an overflow) when trying to verify certain `where` clauses.

This commit causes us to skip generating any impl candidates when an
error type is involved.
Co-authored-by: Randy Taylor <tehgecKozzz@gmail.com>
Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.

We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing
Fixed failing test-cases

Remove noisy suggestion of hash_map rust-lang#72642

Fixed failing test-cases
This commit adds a test of the improper ctypes lint, checking that
return type are normalized bethat return types are normalized before
being checked for FFI-safety, and that transparent newtype wrappers
are FFI-safe if the type being wrapped is FFI-safe.

Signed-off-by: David Wood <david@davidtw.co>
This commit moves the check that skips unit return types to after
where the return type has been normalized - therefore ensuring that
FFI-safety lints are not emitted for types which normalize to unit.

Signed-off-by: David Wood <david@davidtw.co>
This commit ensures that if a `repr(transparent)` newtype's only
non-zero-sized field is FFI-safe then the newtype is also FFI-safe.

Previously, ZSTs were ignored for the purposes of linting FFI-safety
in transparent structs - thus, only the single non-ZST would be checked
for FFI-safety. However, if the non-zero-sized field is a generic
parameter, and is substituted for a ZST, then the type would be
considered FFI-unsafe (as when every field is thought to be zero-sized,
the type is considered to be "composed only of `PhantomData`" which is
FFI-unsafe).

In this commit, for transparent structs, the non-zero-sized field is
identified (before any substitutions are applied, necessarily) and then
that field's type (now with substitutions) is checked for FFI-safety
(where previously it would have been skipped for being zero-sized in
this case).

To handle the case where the non-zero-sized field is a generic
parameter, which is substituted for `()` (a ZST), and is being used
as a return type - the `FfiUnsafe` result (previously `FfiPhantom`) is
caught and silenced.

Signed-off-by: David Wood <david@davidtw.co>
resolve: Do not suggest imports from the same module in which we are resolving

Based on the idea from rust-lang#72623.
…-transparent-improper-ctypes, r=varkor

improper ctypes: normalize return types and transparent structs

Fixes rust-lang#66202.

See each commit individually (except the first which adds a test) for more detailed explanations on the changes made.

In summary, this PR ensures that return types are normalized before being checked for FFI-safety, and that transparent newtype wrappers are FFI-safe if the type being wrapped is FFI-safe (often true previously, but not if, after substitution, all types in a transparent newtype were zero sized).
…r=pnkfelix

normalize adt fields during structural match checking

fixes rust-lang#72896

currently only fixes the issue itself and compiles stage 1 libs.
I believe we have to use something else to normalize the adt fields here,
as I expect some partially resolved adts to cause problems 🤔

stage 1 libs and the test itself pass, not sure about the rest...
Will spend some more time looking into it tomorrow.

r? @pnkfelix cc @eddyb
…ebank

Don't create impl candidates when obligation contains errors

Fixes rust-lang#72839

In PR rust-lang#72621, trait selection was modified to no longer bail out early
when an error type was encountered. This allowed us treat `ty::Error` as
`Sized`, causing us to avoid emitting a spurious "not sized" error after
a type error had already occured.

However, this means that we may now try to match an impl candidate
against the error type. Since the error type will unify with almost
anything, this can cause us to infinitely recurse (eventually triggering
an overflow) when trying to verify certain `where` clauses.

This commit causes us to skip generating any impl candidates when an
error type is involved.
…tion, r=davidtwco

Remove noisy suggestion of hash_map

Remove noisy suggestion of hash_map rust-lang#72642

fixes rust-lang#72642
…tle-span-gone, r=ecstatic-morse

Don't lose empty `where` clause when pretty-printing

Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.

We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing
…rochenkov

Reoder order in which MinGW libs are linked to fix recent breakage

Recent upstream mingw-w64 changes made libmsvcrt depend on libmingwex breaking compilation in some cases when using **external** MinGW.

Applying this change to the master fixes nightly and stage{1,2} build. For stage0 one has to export `RUSTFLAGS_BOOTSTRAP='-C link-arg=-lmsvcrt'` until this PR lands in bootstrap compiler.
Therefore I'm humbly asking to also backport it to the beta and update bootstrap compiler.
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=9

@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 10, 2020
@Dylan-DPC-zz
Copy link
Author

@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 10, 2020
@bors
Copy link
Contributor

bors commented Jun 10, 2020

⌛ Testing commit 2b8f1ec with merge 67a44cb9490ccf486fe73529ec972bcc058c58de...

@bors
Copy link
Contributor

bors commented Jun 10, 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 10, 2020
@Dylan-DPC-zz
Copy link
Author

closing the tree due to the wasm failure

@bors treeclosed p=1000

@Dylan-DPC-zz
Copy link
Author

@bors treeclosed=1000

@ehuss
Copy link
Contributor

ehuss commented Jun 10, 2020

@bors treeclosed-

@Dylan-DPC-zz
Copy link
Author

@bors treeclosed=1000

@Dylan-DPC-zz
Copy link
Author

@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 10, 2020
@bors
Copy link
Contributor

bors commented Jun 10, 2020

⌛ Testing commit 2b8f1ec with merge ec42485...

@bors
Copy link
Contributor

bors commented Jun 11, 2020

☀️ Test successful - checks-azure
Approved by: Dylan-DPC
Pushing ec42485 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 11, 2020
@bors bors merged commit ec42485 into rust-lang:master Jun 11, 2020
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-rha9g8q branch June 17, 2020 19:14
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
@rustbot
Copy link
Collaborator

rustbot commented May 2, 2024

Error: Invalid triagebot.toml at position 61:1:

TOML parse error at line 61, column 1
   |
61 | prioritize_on = ["regression-from-stable-to-stable", "regression-from-stable-to-beta", "regression-from-stable-to-nightly"]
   | ^^^^^^^^^^^^^
unknown field `prioritize_on`, expected `label`

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

@ehuss ehuss removed this from the 1.46 milestone May 2, 2024
@rustbot
Copy link
Collaborator

rustbot commented May 2, 2024

Error: Invalid triagebot.toml at position 61:1:

TOML parse error at line 61, column 1
   |
61 | prioritize_on = ["regression-from-stable-to-stable", "regression-from-stable-to-beta", "regression-from-stable-to-nightly"]
   | ^^^^^^^^^^^^^
unknown field `prioritize_on`, expected `label`

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

@ehuss ehuss added this to the 1.46 milestone May 2, 2024
@rustbot
Copy link
Collaborator

rustbot commented May 2, 2024

Error: Invalid triagebot.toml at position 61:1:

TOML parse error at line 61, column 1
   |
61 | prioritize_on = ["regression-from-stable-to-stable", "regression-from-stable-to-beta", "regression-from-stable-to-nightly"]
   | ^^^^^^^^^^^^^
unknown field `prioritize_on`, expected `label`

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

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. 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.

None yet