normalize adt fields during structural match checking
fixes#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
improper ctypes: normalize return types and transparent structs
Fixes#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).
Enforce unwind invariants
I had a quick look at #72959. The failure message probably needs to be more detailed but I just wanted to check I got the right idea. I have no idea how to right a test for this either...
r? @jonas-schievink
Resolves#72959 (hypothetically)
Resolve E0584 conflict
Adds a new error code (`E0761`) to indicate ambiguity in module file names and an accompanying expanded description to resolve a conflict over `E0584`.
Resolves#73116
Add Item::is_fake for rustdoc
I wasn't aware items _could_ be fake, so I think having a function
mentioning it could be helpful. Also, I'd need to make this change for
cross-crate intra-doc links anyway, so I figured it's better to make the
refactor separate.
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>
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 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>
Revert #71956
...since it caused unsoundness in #73137. Also adds a reduced version of #73137 to the test suite. The addition of the `MaybeInitializedLocals` dataflow analysis has not been reverted, but it is no longer used.
Presumably there is a more targeted fix, but I'm worried that other bugs may be lurking. I'm not yet sure what the root cause of #73137 is.
This will need to get backported to beta.
r? @tmandry
This is only really useful in debug messages, so I've switched to
calling `span_to_string` in any place that causes a `Span` to end up in
user-visible output.
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
Rollup of 8 pull requests
Successful merges:
- #71842 (doc: make impl block collapsible if it has an associated constant)
- #72912 (Add new E0758 error code)
- #73008 (Update RELEASES.md)
- #73090 (Use `LocalDefId` directly in `Resolver::export_map`)
- #73118 (Improve the wording in documentation of std::mem::drop)
- #73124 (Removed lifetime parameters from Explanation of E0207 )
- #73138 (Use shorthand linker strip arguments in order to support MacOS)
- #73143 (Update books)
Failed merges:
r? @ghost
- Use `len` more consistently for the number of elements in a vector,
because that's the usual name.
- Use `additional` more consistently for the number of elements we want
to add, because that's what `Vec::reserve()` uses.
- Use `cap` consistently rather than `capacity`.
- Plus a few other tweaks.
This increases consistency and conciseness.
