…ing aliases

Co-authored-by: Jubilee <[email protected]>

…ed platforms

Document supported targets for `-C link-self-contained`

Move `LinkSelfContainedDefault::True` from wasm_base to wasm32_wasi

This prevents issues with eager parser recovery during macro matching.

This [IIFE] made sense when it was added in
f0683f9 and there was a local variable
scoped to it, but now it only sets two globals, so it does nothing.

[IIFE]: https://developer.mozilla.org/en-US/docs/Glossary/IIFE "immediately invoked function expression"

This CSS was added in 34bd2b8, as
`.since { padding-right: 2px }`, to prevent it from uncomfortably touching
the srclink, which was a separate floated element. It was carried forward
with 962c0a4 to the new `.rightside`, but
its role was replaced with adding " • " between them. All it does now
is pushes the element 2px away from the page's right margin.

Removing this rule changes the page layout, but you have to look for it to
notice it.

This attribute is equivalent to `#[lang = "manually_drop"]`, and the behavior of both are
extended to allow the type to define `Drop`, in which case, that will still be run. Only
the field drop glue is suppressed.

This PR should essentially fully implement rust-lang#100344.

Some additional notes:

`#[manually_drop]` means "do not destroy the fields automatically during
destruction". `ManuallyDrop`, is (or could be) "just"
`#[manually_drop] struct ManuallyDrop<T>(T);`.

The intent is, per the MCP, to allow customization of the drop order, without making the
interface for initializing or accessing the fields of the struct clumsier than a normal
Rust type. It also -- and people did seem excited about this part -- lifts `ManuallyDrop`
from being a special language supported feature to just another user of
`#[manually_drop]`.

There is the question of how this interacts with "insignificant" drop. I had trouble
understanding the comments, but insignificant drop appears to just be a static analysis
tool, and not something that changes behavior. (For example, it's used to detect if a
language change will reorder drops in a meaningful way -- meaning, reorder the
significant drops, not the insignificant ones.) Since it's unlikely to be used for
`#[manually_drop]` types, I don't think it matters a whole lot. And where a destructor
is defined, it would seem to make sense for `#[manually_drop]` types to match exactly
the behavior of `union`, since they both have the shared property that field drop
glue is suppressed.

I looked for all locations that queried for `is_manually_drop` in any form, and found two
difficult cases which are hardcoded for `ManuallyDrop` in particular.

The first is a clippy lint for redundant clones. I don't understand why it special-cases
`ManuallyDrop`, and it's almost certainly wrong for it to special-case `#[manually_drop]`
types in general. However, without understanding the original rationale, I have trouble
figuring the right fix. Perhaps it should simply be deleted altogether.

The second is unions -- specifically, the logic for disabling `DerefMut`.
`my_union.x.y = z` will automatically dereference `my_union.x` if it implements
`DerefMut`, unless it is `ManuallyDrop`, in which case it will not. This is because
`ManuallyDrop` is a pointer back to its content, and so this will automatically call `drop`
on a probably uninitialized field, and is unsafe.

This is true of `ManuallyDrop`, but not necessarily any other `#[manually_drop]` type.
I believe the correct fix would, instead, be a way to mark and detect types which are
a smart pointer whose pointee is within `self`. See, for example, this playground link:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=76fb22a6214ce453538fc18ec35a839d

But that needs to wait for a separate RFC. For now, we apply exactly the same restriction
for `ManuallyDrop` and for any other `#[manually_drop]` type, even though it may be
confusing.

1.  Delete `#[lang = "manually_drop"]`. I'm not sure if anything special needs to be done
    here other than replacing it with `#[manually_drop]` -- is there a compatibility
    guarantee that must be upheld?
2.  (Optional) Fix the redundant clone check to correctly handle `#[manually_drop]`
    structs that aren't `ManuallyDrop`.
3.  When there is more experience with the feature (e.g. in Crubit) create a full RFC
    based on the MCP, and go through the remainder of the stabilization process.
    (Also, do things like generalize the union error messages to not specifically
    mention `ManuallyDrop`, but also mention `#[manually_drop]`. For as long as the
    feature is unstable, the error messages would be confusing if they referenced
    it...)

Co-authored-by: lcnr <[email protected]>

`#crate-search-div` is nested directly below `.search-results-title`, which
has `display: inline-flex`. This makes the crate-search-div a [flex item],
which makes its display property irrelevant, because flex items have their
display [blockified] in any case.

[flex item]: https://developer.mozilla.org/en-US/docs/Glossary/Flex_Item
[blockified]: https://www.w3.org/TR/css-flexbox-1/#flex-items

Add the `#[manually_drop]` attribute.

This attribute is equivalent to `#[lang = "manually_drop"]`, and the behavior of both are extended to allow the type to define `Drop`, in which case, that will still be run. Only the field drop glue is suppressed.

This PR should essentially fully implement rust-lang#100344, and is gated behind the feature flag `manually_drop_attr`.

Some additional notes:

### The meaning of `#[manually_drop]`

`#[manually_drop]` means "do not destroy the fields automatically during destruction". `ManuallyDrop`, could "just", morally speaking, be `#[manually_drop] struct ManuallyDrop<T>(T);`.

The intent is, per the MCP, to allow customization of the drop order, without making the interface for initializing or accessing the fields of the struct clumsier than a normal Rust type. It also -- and people did seem excited about this part -- lifts `ManuallyDrop` from being a special language supported feature to just another user of `#[manually_drop]`.

### Insignificant Drop

There is the question of how this interacts with "insignificant" drop. I had trouble understanding the comments, but insignificant drop appears to just be a static analysis tool, and not something that changes behavior. (For example, it's used to detect if a language change will reorder drops in a meaningful way -- meaning, reorder the significant drops, not the insignificant ones.) Since it's unlikely to be used for `#[manually_drop]` types, I don't think it matters a whole lot. And where a destructor is defined, it would seem to make sense for `#[manually_drop]` types to match exactly the behavior of `union`, since they both have the shared property that field drop glue is suppressed.

### Users that expect `adt.is_manually_drop()` <-> "is `std::mem::ManuallyDrop`"

I looked for all locations that queried for `is_manually_drop` in any form, and found two difficult cases which are hardcoded for `ManuallyDrop` in particular.

The first is a clippy lint for redundant clones. I don't understand why it special-cases `ManuallyDrop`, and it's almost certainly wrong for it to special-case `#[manually_drop]` types in general. However, without understanding the original rationale, I have trouble figuring the right fix. Perhaps it should simply be deleted altogether.

The second is unions -- specifically, the logic for disabling `DerefMut`. `my_union.x.y = z` will automatically dereference `my_union.x` if it implements `DerefMut`, unless it is `ManuallyDrop`, in which case it will not. This is because `ManuallyDrop` is a pointer back to its content, and so this will automatically call `drop` on a probably uninitialized field, and is unsafe.

This is true of `ManuallyDrop`, but not necessarily any other `#[manually_drop]` type. I believe the correct fix would, instead, be a way to mark and detect types which are a smart pointer whose pointee is within `self`. See, for example, this playground link:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=76fb22a6214ce453538fc18ec35a839d

But that needs to wait for a separate RFC. For now, we apply exactly the same restriction for `ManuallyDrop` and for any other `#[manually_drop]` type, even though it may be confusing.

## To-do in future PRs

1.  Delete `#[lang = "manually_drop"]`. I'm not sure if anything special needs to be done here other than replacing it with `#[manually_drop]` -- is there a compatibility guarantee that must be upheld?
2.  (Optional) Fix the redundant clone check to correctly handle `#[manually_drop]` structs that aren't `ManuallyDrop`.
3.  When there is more experience with the feature (e.g. in Crubit) create a full RFC based on the MCP, and go through the remainder of the stabilization process. (Also, do things like generalize the union error messages to not specifically mention `ManuallyDrop`, but also mention `#[manually_drop]`. For as long as the feature is unstable, the error messages would be confusing if they referenced it...)

…ilee

Fix some misleading target feature aliases

This is the first half of a fix for rust-lang#100752.  It looks like these aliases were added in rust-lang#78361 and slipped under the radar, as these features are not AVX512.  These features _do_ add AVX512 instructions when used _in combination_ with AVX512F, but without AVX512F, these features still provide 128-bit and 256-bit vector instructions.  A user might be mislead into thinking these features imply AVX512F (which is true of the actual AVX512 features).  This PR allows using the names as defined by LLVM, which matches Intel documentation.

A future PR should change the `std::arch` intrinsics to use these names, and finally remove these aliases from rustc.

r? ``@workingjubilee``

cc ``@Amanieu``

…d, r=bjorn3

Issue error when -C link-self-contained option is used on unsupported platforms

The documentation was also updated to reflect this.

I'm assuming the supported platforms are the same as initially written in [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler-17).

Fixes rust-lang#103576

…li-obk

cleanup and dedupe CTFE and Miri error reporting

It looks like most of the time, this error raised from const_prop_lint is just redundant -- it duplicates the error reported when evaluating the const-eval query. This lets us make `ConstEvalErr` private to the const_eval module which I think is a good step.

The Miri change mostly replaces a `match` by `if let`, and dedupes the "this error is impossible in Miri" checks.

r? `@oli-obk`
Fixes rust-lang#75461

Only do parser recovery on retried macro matching

Eager parser recovery can break macros, so we don't do it at first. But when we already know that the macro failed, we can retry it with recovery enabled to still emit useful diagnostics.

Helps with rust-lang#103534

various cleanups to try to reduce the use of spans inside method resolution

definitely review commit by commit.

…r=GuillaumeGomez

rustdoc: remove unused JS IIFE from main.js

This [IIFE] made sense when it was added in f0683f9 and there was a local variable scoped to it, but now it only sets two globals, so it does nothing.

[IIFE]: https://developer.mozilla.org/en-US/docs/Glossary/IIFE "immediately invoked function expression"

…ing-right, r=GuillaumeGomez

rustdoc: remove pointless CSS `.rightside { padding-right: 2px }`

This CSS was added in 34bd2b8, as `.since { padding-right: 2px }`, to prevent it from uncomfortably touching the srclink, which were separate floated elements. It was carried forward with 962c0a4 to the new `.rightside`, but its role was replaced with adding " • " between them. All it does now is pushes the element 2px away from the page's right margin.

Removing this rule changes the page layout, but you have to look for it to notice it.

…iv-display, r=GuillaumeGomez

rustdoc: remove no-op CSS `#crate-search-div { display: inline-block }`

`#crate-search-div` is nested directly below `.search-results-title`, which has `display: inline-flex`. This makes the crate-search-div a [flex item], which makes its display property irrelevant, because flex items have their display [blockified] in any case.

[flex item]: https://developer.mozilla.org/en-US/docs/Glossary/Flex_Item
[blockified]: https://www.w3.org/TR/css-flexbox-1/#flex-items