-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 10 pull requests #58426
Rollup of 10 pull requests #58426
Conversation
Instead of inlining the same logic into every number formatting implementation, pull it out into a function that each of the number formatting impls call into.
For smaller code size.
The generic `F` in `with_padding` was causing a bunch of stuff to get inlined that otherwise needn't be, blowing up code size.
This makes the capitalisation consistent and provides more context (especially for missing top-level attributes).
Removes some unsafe *and* saves almost half a kilobyte of code size.
This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant.
This clarifies why FP-units are disabled on UEFI targets, as well as why we must opt into the NXCOMPAT feature. I did find some time to investigate why GRUB and friends disable FP on UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it turns out it does not mandate enabling the instruction sets explicitly. Hence, any use of these instructions will trigger CPU exceptions, unless an application explicitly enables them (which is not an option, as these are global flags that better be controlled by the kernel/firmware). Furthermore, UEFI systems are allowed to mark any non-code page as non-executable. Hence, we must make sure to never place code on the stack or heap. So we better pass /NXCOMPAT to the linker for it to complain if it ever places code in non-code pages. Lastly, this fixes some typos in related comments.
HirId-ify hir::BodyId Another step towards rust-lang#57578.
…r=GuillaumeGomez Ignore future deprecations in #[deprecated] The future deprecation warnings should only apply to `#[rustc_deprecated]` as they take into account rustc's version. Fixes rust-lang#57952. I've also slightly modified rustdoc's display of future deprecation notices to make it more consistent, so I'm assigning a rustdoc team member for review to make sure this is okay. r? @GuillaumeGomez
On return type `impl Trait` for block with no expr point at last semi Partial solution, doesn't actually validate that the last statement in the function body can satisfy the trait bound, but it's a good incremental improvement over the status quo. ``` error[E0277]: the trait bound `(): Bar` is not satisfied --> $DIR/impl-trait-return-trailing-semicolon.rs:3:13 | LL | fn foo() -> impl Bar { | ^^^^^^^^ the trait `Bar` is not implemented for `()` LL | 5; | - consider removing this semicolon | = note: the return type of a function must have a statically known size ``` Partially addresses rust-lang#54771.
…k-Simulacrum Cut down on number formating code size r? @alexcrichton
…evel, r=davidtwco Improve the error messages for missing stability attributes This makes the capitalisation consistent and provides more context (especially for missing top-level attributes).
Only suggest imports if not imported. Fixes rust-lang#42944 and fixes rust-lang#53430. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant. r? @estebank
Fix rustc_driver swallowing errors when compilation is stopped r? @oli-obk
target/uefi: clarify documentation This clarifies why FP-units are disabled on UEFI targets, as well as why we must opt into the NXCOMPAT feature. I did find some time to investigate why GRUB and friends disable FP on UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it turns out it does not mandate enabling the instruction sets explicitly. Hence, any use of these instructions will trigger CPU exceptions, unless an application explicitly enables them (which is not an option, as these are global flags that better be controlled by the kernel/firmware). Furthermore, UEFI systems are allowed to mark any non-code page as non-executable. Hence, we must make sure to never place code on the stack or heap. So we better pass /NXCOMPAT to the linker for it to complain if it ever places code in non-code pages. Lastly, this fixes some typos in related comments. r? @alexcrichton
@bors r+ p=10 |
📌 Commit 01533d4 has been approved by |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Successful merges:
impl Trait
for block with no expr point at last semi #58204 (On return typeimpl Trait
for block with no expr point at last semi)Failed merges:
r? @ghost