Rollup of 6 pull requests #93836
Merged
Rollup of 6 pull requests #93836
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.
…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`.
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?
…wiser Make a few cleanup MIR passes public Zulip Discussion: https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Making.20passes.20public.20again This makes a few passes which used to be public, public again. I'd like to use these to clean up MIR code for my external rustc driver. The other option would be to make them all public, but I don't know if that's warranted / useful. r? `@wesleywiser`
rustbot
added
T-compiler
|
@bors r+ rollup=never p=6 |
|
📌 Commit 3238806 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (5d6ee0d): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
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