https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.84.0 2024-11-20T19:10:12+00:00 2024-11-20T19:10:12+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-11-20T19:10:12+00:00 urn:sha1:7fc2b337229dfb4bc2e410317af271c1b8dbfe6b Point at `const` definition when used instead of a binding in a `let` statement Modify `PatKind::InlineConstant` to be `ExpandedConstant` standing in not only for inline `const` blocks but also for `const` items. This allows us to track named `const`s used in patterns when the pattern is a single binding. When we detect that there is a refutable pattern involving a `const` that could have been a binding instead, we point at the `const` item, and suggest renaming. We do this for both `let` bindings and `match` expressions missing a catch-all arm if there's at least one single binding pattern referenced. After: ``` error[E0005]: refutable pattern in local binding --> $DIR/bad-pattern.rs:19:13 | LL | const PAT: u32 = 0; | -------------- missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable ... LL | let PAT = v1; | ^^^ pattern `1_u32..=u32::MAX` not covered | = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html = note: the matched value is of type `u32` help: introduce a variable instead | LL | let PAT_var = v1; | ~~~~~~~ ``` Before: ``` error[E0005]: refutable pattern in local binding --> $DIR/bad-pattern.rs:19:13 | LL | let PAT = v1; | ^^^ | | | pattern `1_u32..=u32::MAX` not covered | missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable | help: introduce a variable instead: `PAT_var` | = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html = note: the matched value is of type `u32` ``` CC #132582. 2024-11-18T09:38:56+00:00 lcnr rust@lcnr.de 2024-11-15T12:53:31+00:00 urn:sha1:9cba14b95bb07a5b31ed1aac2bf4eadd248232da the behavior of the type system not only depends on the current assumptions, but also the currentnphase of the compiler. This is mostly necessary as we need to decide whether and how to reveal opaque types. We track this via the `TypingMode`. 2024-11-17T23:40:00+00:00 Esteban Küber esteban@kuber.com.ar 2024-11-07T19:34:23+00:00 urn:sha1:f563efec156319d726095a82ea3d0f167c7edac7 2024-11-17T23:39:59+00:00 Esteban Küber esteban@kuber.com.ar 2024-11-06T21:10:31+00:00 urn:sha1:c25b44bee96e4489dab8f44409ba347bfeb328b9 2024-11-17T23:39:59+00:00 Esteban Küber esteban@kuber.com.ar 2024-11-06T19:46:54+00:00 urn:sha1:ff2f7a7a834843ea74b1e7d6511eb4ad06f43981 After: ``` error[E0005]: refutable pattern in local binding --> $DIR/bad-pattern.rs:19:13 | LL | const PAT: u32 = 0; | -------------- missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable ... LL | let PAT = v1; | ^^^ | | | pattern `1_u32..=u32::MAX` not covered | help: introduce a variable instead: `PAT_var` | = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html = note: the matched value is of type `u32` ``` Before: ``` error[E0005]: refutable pattern in local binding --> $DIR/bad-pattern.rs:19:13 | LL | let PAT = v1; | ^^^ | | | pattern `1_u32..=u32::MAX` not covered | missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable | help: introduce a variable instead: `PAT_var` | = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html = note: the matched value is of type `u32` ``` 2024-10-28T04:10:58+00:00 Jubilee Young workingjubilee@gmail.com 2024-10-28T03:38:33+00:00 urn:sha1:4839d6e6e51f29c6bd9b581df520a8f1a6d278b9 Depend on rustc_abi in compiler crates that use it indirectly but have not yet taken on that dependency, and are not entangled in my other PRs. This leaves an "excise rustc_target" step after the dust settles. 2024-10-23T08:14:41+00:00 Ralf Jung post@ralfj.de 2024-10-09T07:01:57+00:00 urn:sha1:ad3991d30382676f987a38243b3097d880b9033a 2024-09-29T11:31:30+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-09-29T11:31:30+00:00 urn:sha1:71cd918dc78c84d41bb89c2fc8effcfd000f4e3e 2024-09-28T11:42:37+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-09-28T11:42:37+00:00 urn:sha1:e174b92cb45138dcea93727e64f2255ae39cd5bf 2024-09-23T04:45:36+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-09-23T04:45:36+00:00 urn:sha1:0e08d7002b6eb44163efbab84cb39d3463c67699 Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis We normalize consts in writeback: #130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`. Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺