about summary refs log tree commit diff
path: root/src/test/ui/structs
AgeCommit message (Collapse)AuthorLines
2021-03-15More precise spans for HIR pathsVadim Petrochenkov-2/+2
2021-03-14Rollup merge of #82789 - csmoe:issue-82772, r=estebankYuki Okushi-5/+7
Get with field index from pattern slice instead of directly indexing Closes #82772 r? ``@estebank`` https://github.com/rust-lang/rust/pull/82789#issuecomment-796921977 > ``@estebank`` So the real cause is we only generate single pattern for Box here https://github.com/csmoe/rust/blob/615b03aeaa8ce9819de7828740ab3cd7def4fa76/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs#L1130-L1132 But in the replacing function, it tries to index on the 1-length pattern slice with field 1, thus out of bounds. https://github.com/csmoe/rust/blob/615b03aeaa8ce9819de7828740ab3cd7def4fa76/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs#L1346
2021-03-12fix: check before index into generated patternscsmoe-17/+3
2021-03-12add ui testcase for issue 82772csmoe-8/+24
2021-03-05Update tests names to start with `issue-`Henry Boisdequin-1/+1
See @JohnTitor's [comment](https://github.com/rust-lang/rust/pull/82720#discussion_r586488083) @rustbot label +C-cleanup
2021-02-25Rollup merge of #82220 - henryboisdequin:fixes-80853, r=varkorDylan DPC-0/+20
fix the false 'defined here' messages Closes #80853. Take this code: ```rust struct S; fn repro_ref(thing: S) { thing(); } ``` Previously, the error message would be this: ``` error[E0618]: expected function, found `S` --> src/lib.rs:4:5 | 3 | fn repro_ref(thing: S) { | ----- `S` defined here 4 | thing(); | ^^^^^-- | | | call expression requires function error: aborting due to previous error ``` This is incorrect as `S` is not defined in the function arguments, `thing` is defined there. With this change, the following is emitted: ``` error[E0618]: expected function, found `S` --> $DIR/80853.rs:4:5 | LL | fn repro_ref(thing: S) { | ----- is of type `S` LL | thing(); | ^^^^^-- | | | call expression requires function | = note: local variable `S` is not a function error: aborting due to previous error ``` As you can see, this error message points out that `thing` is of type `S` and later in a note, that `S` is not a function. This change does seem like a downside for some error messages. Take this example: ``` LL | struct Empty2; | -------------- is of type `Empty2` ``` As you can see, the error message shows that the definition of `Empty2` is of type `Empty2`. Although this isn't wrong, it would be more helpful if it would say something like this (which was there previously): ``` LL | struct Empty2; | -------------- `Empty2` defined here ``` If there is a better way of doing this, where the `Empty2` example would stay the same as without this change, please inform me. **Update: This is now fixed** CC `@camelid`
2021-02-25add helpful error notes and fix the false 'defined here' messagesHenry Boisdequin-0/+20
2021-02-23Rollup merge of #81235 - reese:rw-tuple-diagnostics, r=estebankDylan DPC-0/+40
Improve suggestion for tuple struct pattern matching errors. Closes #80174 This change allows numbers to be parsed as field names when pattern matching on structs, which allows us to provide better error messages when tuple structs are matched using a struct pattern. r? ``@estebank``
2021-02-20Fix suggestion span and move suggestions into new subwindow.Reese Williams-6/+12
2021-02-14Clarify error message and remove pretty printing in help suggestions.Reese Williams-4/+8
2021-01-26Tweak suggestion for missing field in patternsEsteban Küber-2/+2
Account for parser recovered struct and tuple patterns to avoid invalid suggestion. Follow up to #81103.
2021-01-20Improve suggestion for tuple struct pattern matching errors.Reese Williams-0/+30
Currently, when a user uses a struct pattern to pattern match on a tuple struct, the errors we emit generally suggest adding fields using their field names, which are numbers. However, numbers are not valid identifiers, so the suggestions, which use the shorthand notation, are not valid syntax. This commit changes those errors to suggest using the actual tuple struct pattern syntax instead, which is a more actionable suggestion.
2021-01-10Rework diagnostics for wrong number of generic argsPatryk Wychowaniec-19/+37
2020-11-06Fixing Spelling Typosankushduacodes-2/+2
2020-09-11Provide suggestion for missing fields in patternsEsteban Küber-0/+18
2020-09-02pretty: trim paths of unique symbolsDan Aloni-5/+5
If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-07-02Audit uses of `span_suggestion_short`Yuki Okushi-15/+44
2020-05-08Skip tests on emscriptenYuki Okushi-0/+1
2020-05-06Move tests from `test/run-fail` to UIYuki Okushi-0/+17
2020-03-22Normalize wording of privacy access labelsEsteban Küber-4/+4
2020-03-22Add span label to primary error spanEsteban Küber-10/+10
2020-01-16resolve: Point at the private item definitions in privacy errorsVadim Petrochenkov-4/+28
2019-12-30MatchExpressionArmPattern: Use more generic wording.Mazdak Farrokhzad-3/+3
The existing wording was inappropriate for e.g. `if let Ok(_) = expr { .. }`. The diagnostic would leak the fact that we desugar to a `match`.
2019-12-21Update tests for GATsMatthew Jasper-9/+2
* Make some run-pass or check-pass * Use `#![allow(incomplete_features)]` * Update FIXMEs now that some of the issues have been addressed * Add regression tests
2019-11-18Surround types with backticks in type errorsEsteban Küber-18/+18
2019-11-18Remove E0308 note when primary label has all infoEsteban Küber-36/+0
2019-11-18Specific labels when referring to "expected" and "found" typesEsteban Küber-18/+18
2019-11-02Update testsDmitry Kadashev-6/+15
Update the tests to reflect changes to how type mismatch errors are reported (two previous commits).
2019-10-27Gather together usefulness testsNadrieril-59/+0
I took most tests that were testing only for match exhaustiveness, pattern refutability or match arm reachability, and put them in the same test folder.
2019-09-28Implement CRsWojciech Baranowski-1/+1
2019-09-18Add explanation to type mismatch involving type params and assoc typesEsteban Küber-0/+4
2019-08-31Use span label instead of note for cause in E0631Esteban Küber-6/+3
2019-08-11Remove `is_self` and `has_self_ty` methodsMatthew Jasper-6/+6
2019-04-23Auto merge of #60172 - varkor:tidy-double-trailing-newline, r=kennytmbors-1/+0
Disallow double trailing newlines in tidy This wasn't done previously in https://github.com/rust-lang/rust/pull/47064#issuecomment-354533010 as it affected too many files, but I think it's best to fix it now so that the number of files with double trailing newlines doesn't keep increasing. r? kennytm
2019-04-22review comments: deduplicate testsEsteban Küber-54/+4
2019-04-22Continue evaluating after item-type checkingEsteban Küber-7/+22
2019-04-22Remove double trailing newlinesvarkor-1/+0
2019-04-18hide `--explain` hint if error has no extended infoAndy Russell-5/+5
2019-03-25Auto merge of #59240 - euclio:struct-field-span, r=oli-obkbors-1/+1
use the identifier span for missing struct field
2019-03-20Update testsvarkor-12/+12
2019-03-16use the identifier span for missing struct fieldAndy Russell-1/+1
2019-03-11Update testsVadim Petrochenkov-41/+41
2019-03-02Point at enum definition when match patterns are not exhaustiveEsteban Küber-2/+11
``` error[E0004]: non-exhaustive patterns: type `X` is non-empty --> file.rs:9:11 | 1 | / enum X { 2 | | A, | | - variant not covered 3 | | B, | | - variant not covered 4 | | C, | | - variant not covered 5 | | } | |_- `X` defined here ... 9 | match x { | ^ | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms error[E0004]: non-exhaustive patterns: `B` and `C` not covered --> file.rs:11:11 | 1 | / enum X { 2 | | A, 3 | | B, 4 | | C, | | - not covered 5 | | } | |_- `X` defined here ... 11 | match x { | ^ patterns `C` not covered ``` When a match expression doesn't have patterns covering every variant, point at the enum's definition span. On a best effort basis, point at the variant(s) that are missing. This does not handle the case when the missing pattern is due to a field's enum variants: ``` enum E1 { A, B, C, } enum E2 { A(E1), B, } fn foo() { match E2::A(E1::A) { E2::A(E1::B) => {} E2::B => {} } //~^ ERROR `E2::A(E1::A)` and `E2::A(E1::C)` not handled } ``` Unify look between match with no arms and match with some missing patterns. Fix #37518.
2019-01-14Rollup merge of #57477 - euclio:clarify-lev-suggestion, r=zackmdavisMazdak Farrokhzad-1/+1
clarify resolve typo suggestion Include the kind of the binding that we're suggesting, and use a structured suggestion. Fixes #53445.
2019-01-12Reword label as per review commentEsteban Küber-3/+3
2019-01-12Point at the match discriminant when arm pattern has a type mismatchEsteban Küber-0/+6
2019-01-09clarify resolve typo suggestionAndy Russell-1/+1
Include the kind of the binding that we're suggesting, and use a structured suggestion.
2019-01-06tests: Do not use `-Z parse-only`, continue compilation to test recoveryVadim Petrochenkov-11/+9
2019-01-02Auto merge of #57250 - codeworm96:tyerr_msg, r=varkorbors-21/+21
Improve type mismatch error messages Closes #56115. Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing. TODO the book and clippy needs to be changed accordingly later. r? @varkor
2018-12-31Improve type mismatch error messagesYuning Zhang-21/+21
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.