Rollup of 9 pull requests #104489
Closed
Rollup of 9 pull requests #104489
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
rustbot
added
the
A-translation
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 80f51e0 with merge 293784ff1cd706f268316556aacde32b705f461e... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
#[manually_drop]attribute. #101586 (Add the#[manually_drop]attribute.).rightside { padding-right: 2px }#104462 (rustdoc: remove pointless CSS.rightside { padding-right: 2px })#crate-search-div { display: inline-block }#104466 (rustdoc: remove no-op CSS#crate-search-div { display: inline-block })Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup