about summary refs log tree commit diff
path: root/tests/ui/pattern
AgeCommit message (Collapse)AuthorLines
2025-05-06let deref patterns participate in usefulness/exhaustivenessdianne-15/+9
This does not yet handle the case of mixed deref patterns with normal constructors; it'll ICE in `Constructor::is_covered_by`. That'll be fixed in a later commit.
2025-05-05always peel `&mut`, to allow matching on `&mut str`dianne-3/+143
2025-05-05match ergonomics for string and byte string literal patternsdianne-41/+156
2025-05-04Auto merge of #140616 - petrochenkov:noannempty, r=jieyouxubors-2/+1
compiletest: Do not require annotations on empty labels and suggestions Unlike other empty diagnostics, empty labels (only underlining spans) and empty suggestions (suggestions to remove something) are quite usual and do not require any special attention and annotations. This effectively reverts a part of https://github.com/rust-lang/rust/pull/139485. r? `@jieyouxu`
2025-05-03compiletest: Do not require annotations on empty labels and suggestionsVadim Petrochenkov-2/+1
2025-05-03Move some tests out of tests/uimejrs-0/+26
2025-04-30compiletest: Make diagnostic kind mandatory on line annotationsVadim Petrochenkov-307/+331
2025-04-27Test partial moves via deref patsNadrieril-0/+8
2025-04-24lower deref patterns on boxes using built-in derefsdianne-0/+47
This allows deref patterns to move out of boxes. Implementation-wise, I've opted to put the information of whether a deref pattern uses a built-in deref or a method call in the THIR. It'd be a bit less code to check `.is_box()` everywhere, but I think this way feels more robust (and we don't have a `mutability` field in the THIR that we ignore when the smart pointer's a box). I'm not sure about the naming (or using `ByRef`), though.
2025-04-24move existing tests away from using boxesdianne-50/+96
Since deref patterns on boxes will be lowered differently, I'll be making a separate test file for them. This makes sure we're still testing the generic `Deref(Mut)::deref(_mut)`-based lowering.
2025-04-24Rollup merge of #140028 - dianne:lit-deref-pats-p1, r=oli-obkMatthias Krüger-29/+244
`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on #138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests). This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1]. This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals. This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes. The update to the unstable book added by this will conflict with #140022, so they shouldn't be merged at the same time. Tracking issue for deref patterns: #87121 r? ``@oli-obk`` cc ``@Nadrieril`` [^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see #44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.
2025-04-22make `[u8]` and `[u8;N]` literal patterns usable in deref patternsdianne-1/+147
Specifically, this allows byte string literal patterns to be used where a `[u8]` or `[u8;N]` is expected when `deref_patterns` is enabled.
2025-04-22make `str` literal patterns usable in deref patternsdianne-29/+54
Specifically, this allows string literal patterns to be used where a `str` is expected when `deref_patterns` is enabled.
2025-04-22add a test for byte string literal pattern mutability mismatchesdianne-0/+44
2025-04-19Rollup merge of #139042 - compiler-errors:do-not-optimize-switchint, r=saethlinChris Denton-0/+24
Do not remove trivial `SwitchInt` in analysis MIR This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory. This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB. Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like: ```rust fn foo() { let x; let (0 | _) = x; } ``` This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: https://github.com/rust-lang/rust/pull/139042#issuecomment-2767436367 As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.: ```rust fn foo() { let x; let (0.. | _) = x; } ```
2025-04-18Rollup merge of #138528 - dianne:implicit-deref-patterns, r=NadrierilMatthias Krüger-6/+437
deref patterns: implement implicit deref patterns This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter. Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring. Tracking issue: #87121 r? ``@Nadrieril``
2025-04-17Auto merge of #139949 - matthiaskrgr:rollup-pxc5tsx, r=matthiaskrgrbors-5/+5
Rollup of 8 pull requests Successful merges: - #138632 (Stabilize `cfg_boolean_literals`) - #139416 (unstable book; document `macro_metavar_expr_concat`) - #139782 (Consistent with treating Ctor Call as Struct in liveness analysis) - #139885 (document RUSTC_BOOTSTRAP, RUSTC_OVERRIDE_VERSION_STRING, and -Z allow-features in the unstable book) - #139904 (Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests) - #139932 (transmutability: Refactor tests for simplicity) - #139944 (Move eager translation to a method on Diag) - #139948 (git: ignore `60600a6fa403216bfd66e04f948b1822f6450af7` for blame purposes) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-17Rollup merge of #138632 - clubby789:stabilize-cfg-boolean-lit, ↵Matthias Krüger-5/+5
r=davidtwco,Urgau,traviscross Stabilize `cfg_boolean_literals` Closes #131204 `@rustbot` labels +T-lang +I-lang-nominated This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating -- # Stabilization Report ## General design ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? [RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none. ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? None ## Has a call-for-testing period been conducted? If so, what feedback was received? Yes; only positive feedback was received. ## Implementation quality ### Summarize the major parts of the implementation and provide links into the code (or to PRs) Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034). ### Summarize existing test coverage of this feature - [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs) - [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs) - [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs) - [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs) - Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs` - Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs` ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? The above mentioned issue; it should not block as it interacts with another unstable feature. ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization - `@clubby789` (RFC) - `@Urgau` (Implementation in rustc) ### Which tools need to be adjusted to support this feature. Has this work been done? `rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized. ## Type system and execution rules ### What updates are needed to the reference/specification? (link to PRs when they exist) A few lines to be added to the reference for configuration predicates, specified in the RFC.
2025-04-16Make cow_of_cow test a teeny bit more explicitNadrieril-1/+2
2025-04-16add a feature gate testdianne-0/+44
Implicit deref patterns allow previously ill-typed programs. Make sure they're still ill-typed without the feature gate. I've thrown in a test for `deref!(_)` too, though it seems it refers to `deref_patterns` as a library feature.
2025-04-16upvar inference for implicit deref patternsdianne-0/+27
2025-04-16respect the tcx's recursion limit when peelingdianne-0/+41
2025-04-16don't peel ADTs the pattern could matchdianne-0/+79
This is the use for the previous commits' refactors; see the messages there for more information.
2025-04-16register `DerefMut` bounds for implicit mutable derefsdianne-3/+62
2025-04-16pattern typing for immutable implicit deref patternsdianne-3/+183
2025-04-16Remove old diagnostic notes for type ascription syntaxZalathar-2/+0
Type ascription syntax was removed in 2023.
2025-04-08Do not optimize out SwitchInt before borrowck, or if Zmir-preserve-ubMichael Goulet-0/+24
2025-04-08UI tests: add missing diagnostic kinds where possibleVadim Petrochenkov-52/+52
2025-04-08borrowck typeck children together with their parentlcnr-26/+92
2025-04-03Use `cfg(false)` in UI testsclubby789-5/+5
2025-03-21remove `feature(inline_const_pat)`lcnr-17/+60
2025-03-15Rollup merge of #138460 - xizheyin:issue-138319, r=petrochenkovLeón Orell Valerian Liehr-0/+22
Pass struct field HirId when check_expr_struct_fields Fixes #138319 r? compiler cc ``@Mark-Simulacrum``
2025-03-14Pass precise HirId when calling check_stabilityxizheyin-0/+22
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-03-13EUV: fix place of deref pattern's interior's scrutineedianne-0/+15
The place previously used here was that of the temporary holding the reference returned by `Deref::deref` or `DerefMut::deref_mut`. However, since the inner pattern of `deref!(inner)` expects the deref-target type itself, this would ICE when that type was inspected (e.g. by the EUV case for slice patterns). This adds a deref projection to fix that. Since current in-tree consumers of EUV (upvar inference and clippy) don't care about Rvalues, the place could be simplified to `self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save some cycles. I personally find EUV to be a bit fragile, so I've opted for pedantic correctness. Maybe a `HACK` comment would suffice though?
2025-03-11Implement `#[define_opaque]` attribute for functions.Oli Scherer-40/+46
2025-02-25Make E0614 a structured errorEsteban Küber-2/+2
``` error[E0614]: type `(..., ..., ..., ...)` cannot be dereferenced --> $DIR/long-E0614.rs:10:5 | LL | *x; | ^^ can't be dereferenced | = note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt' = note: consider using `--verbose` to print the full type name to the console ```
2025-02-21Trim suggestion part before generating highlightsMichael Goulet-21/+21
2025-02-21More sophisticated span trimmingMichael Goulet-18/+12
2025-02-20Auto merge of #137295 - matthiaskrgr:rollup-tdu3t39, r=matthiaskrgrbors-1/+31
Rollup of 9 pull requests Successful merges: - #135296 (interpret: adjust vtable validity check for higher-ranked types) - #137106 (Add customized compare for Link in rustdoc) - #137253 (Restrict `bevy_ecs` `ParamSet` hack) - #137262 (Make fewer crates depend on `rustc_ast_ir`) - #137263 (Register `USAGE_OF_TYPE_IR_INHERENT`, remove inherent usages) - #137266 (MIR visitor tweaks) - #137269 (Pattern Migration 2024: properly label `&` patterns whose subpatterns are from macro expansions) - #137277 (stabilize `inherent_str_constructors`) - #137281 (Tweak "expected ident" parse error to avoid talking about doc comments) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-19don't get trapped inside of expansions when trimming labelsdianne-6/+3
2025-02-19add a failing testdianne-1/+34
2025-02-18"classic2021" ruleset: experimentally add fallback-to-outer (eat both)dianne-116/+54
My reasoning: the ruleset implemented by the same feature gate in Edition 2024 always tries to eat the inherited reference first. For consistency, it makes sense to me to say across all editions that users should consider the inherited reference's mutability when wondering if a `&mut` pattern will type.
2025-02-18add mixed-edition testsdianne-0/+486
2025-02-18"structural2021" ruleset: add fallback-to-outer (eat both) deref ruledianne-173/+114
2025-02-18"classic2021" and "structural2021" rulesets: add eat-inherited-ref-alone ↵dianne-514/+163
deref rules
2025-02-18remove old edition-2021-specific testsdianne-187/+0
These are superseded by the old-edition revisions on the shared tests.
2025-02-18add test revisions for old-edition behavior of feature gatesdianne-322/+1783
This also adds `#[cfg]` attributes to tests for bindings' types, to make it visually clearer which revisions type successfully.
2025-02-18Rollup merge of #137161 - dianne:pat-migration-bookkeeping-for-macros, ↵Matthias Krüger-1/+36
r=Nadrieril Pattern Migration 2024: fix incorrect messages/suggestions when errors arise in macro expansions See the diff between the two commits for how this affected the error message and suggestion. In order to decide how to format those, the pattern migration diagnostic keeps track of which parts of the user's pattern cause problems in Edition 2024. However, it neglected to do some of this bookkeeping when pointing to macro expansion sites. This fixes that.
2025-02-16bookkeep properly when pointing into macro expansionsdianne-2/+6
2025-02-16add a failing testdianne-1/+32