about summary refs log tree commit diff
path: root/src/test/ui/block-result
AgeCommit message (Collapse)AuthorLines
2019-04-18hide `--explain` hint if error has no extended infoAndy Russell-2/+2
2019-04-09improve unknown enum variant errorsAndy Russell-1/+1
2019-03-11Update testsVadim Petrochenkov-13/+13
2019-03-02Suggest removal of `&` when borrowing macro and appropriateEsteban Küber-1/+4
Fix #58815.
2019-01-20Use structured suggestion in stead of notesEsteban Küber-3/+1
2019-01-12Reword label as per review commentEsteban Küber-1/+1
2019-01-12Point at the match discriminant when arm pattern has a type mismatchEsteban Küber-0/+2
2018-12-30Tweak E0308 error for clarityEsteban Küber-5/+5
2018-12-30Point at function name spanEsteban Küber-5/+15
2018-12-30Point at the return type span on type mismatch due to missing returnEsteban Küber-44/+30
Do not point at the entire block span on fn return type mismatches caused by missing return.
2018-12-25Remove licensesMark Rousskov-138/+18
2018-12-24make non_camel_case_types an early lintAndy Russell-2/+2
2018-11-10in which the E0618 "expected function" diagnostic gets a makeoverZack M. Davis-2/+10
Now the main span focuses on the erroneous not-a-function callee, while showing the entire call expression is relegated to a secondary span. In the case where the erroneous callee is itself a call, we point out the definition, and, if the call expression spans multiple lines, tentatively suggest a semicolon (because we suspect that the "outer" call is actually supposed to be a tuple). The new `bug!` assertion is, in fact, safe (`confirm_builtin_call` is only called by `check_call`, which is only called with a first arg of kind `ExprKind::Call` in `check_expr_kind`). Resolves #51055.
2018-10-23fix typos in various placesMatthias Krüger-1/+1
2018-03-14update testsGuillaume Gomez-14/+14
2018-02-26Update UI testsVadim Petrochenkov-4/+4
2018-02-26Update UI testsVadim Petrochenkov-40/+40
2018-02-25Update ui testsGuillaume Gomez-0/+14
2018-01-15Further tweaks to the outputEsteban Küber-1/+1
- Properly address Variant Ctors - Show signature if span of trait method without `self` is not available
2017-12-14Remove NOTE/HELP annotations from UI testsVadim Petrochenkov-10/+10
2017-11-24Merge cfail and ui tests into ui testsOliver Schneider-6/+5
2017-11-18move the signature into the closure typeNiko Matsakis-12/+1
2017-09-21Add suggestions for misspelled method namesThomas Jespersen-0/+2
Use the syntax::util::lev_distance module to provide suggestions when a named method cannot be found. Part of #30197
2017-08-09Readd backticks around ()Esteban Küber-4/+4
2017-08-08Only refer to return type when it matchesEsteban Küber-4/+4
2017-07-25Point at return type always when type mismatch against itEsteban Küber-0/+9
Before this, the diagnostic errors would only point at the return type when changing it would be a possible solution to a type error. Add a label to the return type without a suggestion to change in order to make the source of the expected type obvious. Follow up to #42850, fixes #25133, fixes #41897.
2017-07-21Adjust new suggestions to the suggestion guidelinesOliver Schneider-2/+2
2017-07-06Only underline suggestion if it is not the only code being shownEsteban Küber-2/+6
2017-07-02report the total number of errors on compilation failureAriel Ben-Yehuda-12/+12
Prior to this PR, when we aborted because a "critical pass" failed, we displayed the number of errors from that critical pass. While that's the number of errors that caused compilation to abort in *that place*, that's not what people really want to know. Instead, always report the total number of errors, and don't bother to track the number of errors from the last pass that failed. This changes the compiler driver API to handle errors more smoothly, and therefore is a compiler-api-[breaking-change]. Fixes #42793.
2017-06-27Review commentsEsteban Küber-4/+0
- Fix typo - Add docstring - Remove spurious test output file
2017-06-24Don't naively point to return type on type errorEsteban Küber-17/+2
2017-06-24Do not specify return type in suggestion for some `Ty`sEsteban Küber-2/+2
Don't specify a suggested return type for `TyAnon`, `TyFnDef`, `TyFnPtr`, `TyDynamic`, `TyClosure` and `TyProjection`.
2017-06-24Suggest removal of semicolon (instead of being help)Esteban Küber-25/+5
2017-06-24Detect missing `;` on methods with return type `()`Esteban Küber-0/+23
- Point out the origin of a type requirement when it is the return type of a method - Point out possibly missing semicolon when the return type is () and the implicit return makes sense as a statement - Suggest changing the return type of methods with default return type - Don't suggest changing the return type on fn main() - Don't suggest changing the return type on impl fn
2017-06-23Move tests to `ui`Esteban Küber-0/+499