-
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 8 pull requests #85720
Rollup of 8 pull requests #85720
Conversation
Emit a diagnostic when the monomorphized item collector encounters errors during a step of the recursive item collection. These post-monomorphization errors otherwise only show the erroneous expression without a trace, making them very obscure and hard to pinpoint whenever they happen in dependencies.
This test reproduces post-monomorphization errors one can encounter when using incorrect immediate arguments to some of the stdarch intrinsics using const generics.
…nkov Disallow shadowing const parameters This pull request fixes rust-lang#85348. Trying to shadow a `const` parameter as follows: ```rust fn foo<const N: i32>() { let N @ _ = 0; } ``` currently causes an ICE. With my changes, I get: ``` error[E0530]: let bindings cannot shadow const parameters --> test.rs:2:9 | 1 | fn foo<const N: i32>() { | - the const parameter `N` is defined here 2 | let N @ _ = 0; | ^ cannot be named the same as a const parameter error: aborting due to previous error ``` This is the same error you get when trying to shadow a constant: ```rust const N: i32 = 0; let N @ _ = 0; ``` ``` error[E0530]: let bindings cannot shadow constants --> src/lib.rs:3:5 | 2 | const N: i32 = 0; | ----------------- the constant `N` is defined here 3 | let N @ _ = 0; | ^ cannot be named the same as a constant error: aborting due to previous error ``` The reason for disallowing shadowing in both cases is described [here](rust-lang#33118 (comment)) (the comment there only talks about constants, but the same reasoning applies to `const` parameters).
…panics, r=nagisa Prevent double drop in `Vec::dedup_by` if a destructor panics Fixes rust-lang#85613
…, r=nikomatsakis Fix a few details in THIR unsafeck This makes it consistent with RFC 2585 (`unsafe_op_in_unsafe_fn`) and with the MIR unsafeck. r? `@nikomatsakis`
Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in rust-lang#85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments, and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen, so only when building code that actually uses these code paths. Check builds don't trigger them, neither does unused code) So in this PR, we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors, we print a diagnostic about the current collection step, so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue rust-lang#85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a, b, 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that rust-lang#85155 is a reduced version of a case happening in the wild, to indirect users of the `rustfft` crate, as seen in ejmahler/RustFFT#74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed: <details> ``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0], rows[2], 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self, 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self), _mm_permute_pd(self, 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. error: could not compile `rustfft` To learn more, run the command again with --verbose. ``` </details> I've developed and discussed this with them, so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155, as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli, but we decided to not include them in this PR for now)
Remove arrays/IntoIterator message from Iterator trait. Arrays implement IntoIterator since 1.53. cc rust-lang#84513
fix `matches!` and `assert_matches!` on edition 2021 Previously this code failed to compile on edition 2021. [(Playground)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=53960f2f051f641777b9e458da747707) ```rust fn main() { matches!((), ()); } ``` ``` Compiling playground v0.0.1 (/playground) error: `$pattern:pat` may be followed by `|`, which is not allowed for `pat` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: aborting due to previous error error: could not compile `playground` To learn more, run the command again with --verbose. ```
Remove num_as_ne_bytes feature From the discussion in rust-lang#76976, it is determined that eventual results of the safe transmute work as a more general mechanism will let these conversions happen in safe code without needing specialized methods. Merging this PR closes rust-lang#76976 and resolves rust-lang#64464. Several T-libs members have raised their opinion that it doesn't pull its weight as a standalone method, and so we should not track it as a specific thing to add.
Fix typo in core::array::IntoIter comment Saw a small typo reading some internal comments and decided to just throw this up to fix it for future readers.
@bors r+ rollup=never p=5 |
📌 Commit 9ee87c7 has been approved by |
⌛ Testing commit 9ee87c7 with merge 50f2c6dde4972cf942dc9dbb8e498304b260a432... |
💔 Test failed - checks-actions |
@bors retry |
A job failed! Check out the build log: (web) (plain) Click to see the possible cause of the failure (guessed by this bot)
|
⌛ Testing commit 9ee87c7 with merge 41092cfe0490e1af46032edcefa0fcc5ad34bc29... |
💔 Test failed - checks-actions |
A job failed! Check out the build log: (web) (plain) Click to see the possible cause of the failure (guessed by this bot)
|
@bors retry p=1000 |
@bors treeclosed-- |
@bors treeclosed- |
☀️ Test successful - checks-actions |
Successful merges:
Vec::dedup_by
if a destructor panics #85625 (Prevent double drop inVec::dedup_by
if a destructor panics)matches!
andassert_matches!
on edition 2021 #85678 (fixmatches!
andassert_matches!
on edition 2021)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup