Rollup of 6 pull requests #93834
Closed
Rollup of 6 pull requests #93834
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
…o::metadata more generally applicable.
…accidentally been removed in rust-lang#89597. Also describe vtables as structs with a field for each entry.
We recently removed the "up here" arrows on item-infos, and adjusted vertical spacing so that even without the arrow, it would be visually clear which item the item-info belonged to. The new CSS styles for vertical spacing only applied to toggles, though. This missed non-toggled impl blocks - for instance, those without any methods, like https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#implementors. The result was lists of implementors that were spaced too closely. This PR fixes the spacing by making it apply to non-toggled impl blocks as well. This also fixes an issue where item-infos were displayed too far below their items. That was a result of display: table on .item-info .stab. Changed that to display: inline-block.
…ice, r=wesleywiser Better suggestions when user tries to collect into an unsized `[_]` 1. Extend the predicate on `rustc_on_unimplemented` to support substitutions like note, label, etc (i.e. treat it as a `OnUnimplementedFormatString`) so we can have slightly more general `rustc_on_unimplemented` special-cases. 2. Add a `rustc_on_unimplemented` if we fail on `FromIterator<A> for [A]` which happens when we don't explicitly collect into a `vec<A>`, but then pass the return from a `.collect` call into something that takes a slice. Fixes rust-lang#91423
`#[used(linker)]` attribute See dtolnay/linkme#41 (comment).
…debuginfo-regression, r=wesleywiser debuginfo: Fix DW_AT_containing_type vtable debuginfo regression This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in rust-lang#89597. It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers, the compiler will now emit a struct type description with a field for each entry of the vtable. r? `@wesleywiser` This PR should fix issue rust-lang#93164. ~~The PR is blocked on rust-lang#93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~
…henkov Complete removal of #[main] attribute from compiler resolves rust-lang#93786 --- The `#[main]` attribute was mostly removed from the language in rust-lang#84217, but not completely. It is still recognized as a builtin attribute by the compiler, but it has no effect. However, this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists), so it's possible to include it in code *on stable* without any errors, which seems unintentional. For example, the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!("hello world"); } ``` Aside from that oddity, the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According rust-lang#84062 (comment), the removal of `#[main]` was expected to eliminate this conflict (previously reported as rust-lang#62127). ```rust use tokio::main; #[main] fn main() { println!("hello world"); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114), as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional, and to needlessly block use of the `main` identifier in the attribute namespace, this PR finishes removing the `#[main]` attribute as described in rust-lang#29634 (comment) by deleting it from `builtin_attrs.rs`, and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.
…umeGomez rustdoc: fix spacing of non-toggled impl blocks We [recently removed the "up here" arrows on item-infos](rust-lang#92651), and adjusted vertical spacing so that even without the arrow, it would be visually clear which item the item-info belonged to. The new CSS styles for vertical spacing only applied to toggles, though. This missed non-toggled impl blocks - for instance, those without any methods, like https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#implementors. The result was lists of implementors that were spaced too closely. This PR fixes the spacing by making it apply to non-toggled impl blocks as well. This also fixes an issue where item-infos were displayed too far below their items. That was a result of display: table on .item-info .stab. Changed that to display: inline-block. Demo: https://rustdoc.crud.net/jsha/re-space-empty-impls/std/marker/trait.Send.html Before: <img width=300 src="https://user-images.githubusercontent.com/220205/152954394-ec0b80e7-2573-4f06-9d7a-7b10b8ceac60.png"> After: <img width=300 src="https://user-images.githubusercontent.com/220205/152954228-abac1d30-a76d-4ab1-89ec-ef7549fe8c9c.png"> r? `@GuillaumeGomez`
Fix typo in `std::fmt` docs Hey! Reading the docs (https://doc.rust-lang.org/std/fmt/#named-parameters), this seems like a typo? The docs here also seem to mix “named argument” and “named parameter”? Intentional? Mistake?
rustbot
added
T-compiler
|
@bors r+ rollup=never p=6 |
|
📌 Commit 07d0299 has been approved by |
bors
added
the
S-waiting-on-bors
|
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:
[_]#91443 (Better suggestions when user tries to collect into an unsized[_])#[used(linker)]attribute #91504 (#[used(linker)]attribute)std::fmtdocs #93799 (Fix typo instd::fmtdocs)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup