about summary refs log tree commit diff
path: root/src/test/ui/issues
AgeCommit message (Collapse)AuthorLines
2019-12-22Auto merge of #67505 - Centril:rollup-7win7ty, r=Centrilbors-31/+29
Rollup of 6 pull requests Successful merges: - #67148 ( Refactor type & bounds parsing thoroughly) - #67410 (Reenable static linking of libstdc++ on windows-gnu) - #67439 (Cleanup `lower_pattern_unadjusted` & Improve slice pat typeck) - #67480 (Require issue = "none" over issue = "0" in unstable attributes) - #67500 (Tweak non_shorthand_field_patterns' suggestion) - #67504 (Warn against relying on ?Sized being last) Failed merges: r? @ghost
2019-12-22Rollup merge of #67480 - rossmacarthur:fix-41260-avoid-issue-0-part-2, r=CentrilMazdak Farrokhzad-26/+26
Require issue = "none" over issue = "0" in unstable attributes These changes make the use of `issue = "none"` required in unstable attributes throughout the compiler. Notes: - #66299 is now in beta so `issue = "none"` is accepted. - The `tidy` tool now fails on `issue = "0"`. - Tests that used `issue = "0"` were changed to use `issue = "none"`, except for _one_ that asserts `issue = "0"` can still be used. - The compiler still allows `issue = "0"` because some submodules require it, this could be disallowed once these are updated. Resolves #41260 r? @varkor
2019-12-21add build-fail to 32-bit testsMazdak Farrokhzad-1/+2
2019-12-21rework run-fail and support check,build-failMazdak Farrokhzad-64/+81
2019-12-21span_suggestion_hidden -> tool_only_span_suggestionMazdak Farrokhzad-2/+0
2019-12-21parse_generic_bounds: account for negative lifetime boundsMazdak Farrokhzad-4/+4
2019-12-21Require issue = "none" over issue = "0" in unstable attributesRoss MacArthur-26/+26
2019-12-20Rollup merge of #67354 - VirrageS:blame-wrong-line, r=estebankMazdak Farrokhzad-0/+34
Fix pointing at arg when cause is outside of call Follow up after: #66933 Closes: #66923 r? @estebank
2019-12-20Rollup merge of #67131 - Centril:item-merge, r=petrochenkovMazdak Farrokhzad-3/+18
Merge `TraitItem` & `ImplItem into `AssocItem` In this PR we: - Merge `{Trait,Impl}Item{Kind?}` into `AssocItem{Kind?}` as discussed in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286. - This is done by using the cover grammar of both forms. - In particular, it requires that we syntactically allow (under `#[cfg(FALSE)]`): - `default`ness on `trait` items, - `impl` items without a body / definition (`const`, `type`, and `fn`), - and associated `type`s in `impl`s with bounds, e.g., `type Foo: Ord;`. - The syntactic restrictions are replaced by semantic ones in `ast_validation`. - Move syntactic restrictions around C-variadic parameters from the parser into `ast_validation`: - `fn`s in all contexts now syntactically allow `...`, - `...` can occur anywhere in the list syntactically (`fn foo(..., x: usize) {}`), - and `...` can be the sole parameter (`fn foo(...) {}`. r? @petrochenkov
2019-12-20Rollup merge of #67285 - ohadravid:indicate-origin-of-where-type-parameter, ↵Mazdak Farrokhzad-8/+8
r=estebank Indicate origin of where type parameter for uninferred types Based on #65951 (which is not merge yet), fixes #67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
2019-12-20Rollup merge of #67127 - estebank:disambiguate-suggestion, r=varkorMazdak Farrokhzad-6/+20
Use structured suggestion for disambiguating method calls Fix #65635.
2019-12-19Rollup merge of #67189 - LeSeulArtichaut:binop-wording, r=estebankMazdak Farrokhzad-36/+36
Unify binop wording Closes #60497 r? @estebank
2019-12-15Auto merge of #67216 - ecstatic-morse:const-loop, r=oli-obkbors-2/+6
Enable `loop` and `while` in constants behind a feature flag This PR is an initial implementation of #52000. It adds a `const_loop` feature gate, which allows `while` and `loop` expressions through both HIR and MIR const-checkers if enabled. `for` expressions remain forbidden by the HIR const-checker, since they desugar to a call to `IntoIterator::into_iter`, which will be rejected anyways. `while` loops also require [`#![feature(const_if_match)]`](https://github.com/rust-lang/rust/pull/66507), since they have a conditional built into them. The diagnostics from the HIR const checker will suggest this to the user. r? @oli-obk cc @rust-lang/wg-const-eval
2019-12-14Indicate origin of where type parameter for uninferred typesOhad Ravid-8/+8
2019-12-13Auto merge of #65951 - estebank:type-inference-error, r=nikomatsakisbors-23/+38
Point at method call when type annotations are needed - Point at method call instead of whole expression when type annotations are needed. - Suggest use of turbofish on function and methods. Fix #49391, fix #46333, fix #48089. CC #58517, #63502, #63082. Fixes https://github.com/rust-lang/rust/issues/40015 r? @nikomatsakis
2019-12-13Rollup merge of #67026 - Nadrieril:improve-usefulness-empty, ↵Mazdak Farrokhzad-2/+2
r=varkor,Centril,estebank Improve diagnostics and code for exhaustiveness of empty matches There was a completely separate check and diagnostics for the case of an empty match. This led to slightly different error messages and duplicated code. This improves code reuse and generally clarifies what happens for empty matches. This also clarifies the action of the `exhaustive_patterns` feature, and ensures that this feature doesn't change diagnostics in places it doesn't need to.
2019-12-13Bless unrelated tests with new help messageDylan MacKenzie-2/+6
2019-12-12Added missing backticksLeSeulArtichaut-2/+2
2019-12-12Update testsLeSeulArtichaut-17/+17
2019-12-12Update UI test expectationsLeSeulArtichaut-19/+19
2019-12-12Use `Option` in `ImplItemKind::Method`.Mazdak Farrokhzad-2/+17
2019-12-12Alias `TraitItem` & `ImplItem`.Mazdak Farrokhzad-1/+1
Allow defaultness on trait items syntactically.
2019-12-11Use structured suggestion for disambiguating method callsEsteban Küber-6/+20
Fix #65635.
2019-12-11Add more context for type parametersEsteban Küber-12/+12
2019-12-10Avoid invalid suggestion by checking the snippet in const fn callEsteban Küber-4/+1
2019-12-10missing test change, bad suggestionEsteban Küber-1/+4
2019-12-10Use the appropriate number of type arguments in suggestionEsteban Küber-4/+4
2019-12-10Deduplicate logicEsteban Küber-13/+23
2019-12-10Point at method call when type annotations are neededEsteban Küber-3/+8
2019-12-10Auto merge of #67039 - xfix:manually-implement-pin-traits, r=nikomatsakisbors-0/+40
Use deref target in Pin trait implementations Using deref target instead of pointer itself avoids providing access to `&Rc<T>` for malicious implementations, which would allow calling `Rc::get_mut`. This is a breaking change necessary due to unsoundness, however the impact of it should be minimal. This only fixes the issue with malicious `PartialEq` implementations, other `Pin` soundness issues are still here. See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311/73> for more details.
2019-12-08Rollup merge of #66325 - BartMassey:master, r=joshtriplettMazdak Farrokhzad-1/+1
Change unused_labels from allow to warn Fixes #66324, making the unused_labels lint warn instead of allow by default. I'm told @rust-lang/lang will need to review this, and perhaps will want to do a crater run.
2019-12-07Auto merge of #66927 - RalfJung:engines-dont-panic, r=oli-obkbors-191/+37
Miri core engine: use throw_ub instead of throw_panic See https://github.com/rust-lang/rust/issues/66902 for context: panicking is not really an "interpreter error", but just part of a normal Rust execution. This is a first step towards removing the `InterpError::Panic` variant: the core Miri engine does not use it any more. ConstProp and ConstEval still use it, though. This will be addressed in future PRs. From what I can tell, all the error messages this removes are actually duplicates. r? @oli-obk @wesleywiser
2019-12-07Rename tests and add short test descriptionJanusz Marcinkiewicz-21/+23
2019-12-06Rollup merge of #67009 - Aaron1011:fix/coerce-suggestion, r=CentrilMazdak Farrokhzad-8/+22
Emit coercion suggestions in more places Fixes #66910 We have several different kinds of suggestions we can try to make when type coercion fails. However, we were previously only emitting these suggestions from `demand_coerce_diag`. This resulted in the compiler failing to emit applicable suggestions in several different cases, such as when the implicit return value of a function had the wrong type. This commit adds a new `emit_coerce_suggestions` method, which tries to emit a number of related suggestions. This method is called from both `demand_coerce_diag` and `CoerceMany::coerce_inner`, which covers a much wider range of cases than before. We now suggest using `.await` in more cases where it is applicable, among other improvements. I'm not happy about disabling the `issue-59756`, but from what I can tell, the suggestion infrastructure in rustc lacks any way of indicating mutually exclusive suggestions (and compiletest lacks a way to only apply a subset of available suggestions).
2019-12-06Rollup merge of #66606 - christianpoveda:mut-refs-in-const-fn, r=oli-obkMazdak Farrokhzad-7/+16
Add feature gate for mut refs in const fn r? @oli-obk
2019-12-06Fix pointing at arg when cause is outside of callJanusz Marcinkiewicz-0/+32
2019-12-06Rollup merge of #66979 - reese:E0631-long-error, r=GuillaumeGomezYuki Okushi-2/+4
Add long error for E0631 and update ui tests. This PR adds a long error for `E0631`, which covers errors where closure argument types are mismatched. It also updates UI tests where this error is applicable. Part of #61137
2019-12-05Rollup merge of #67044 - Centril:67037, r=estebankMazdak Farrokhzad-0/+43
E0023: handle expected != tuple pattern type Fixes #67037. r? @estebank
2019-12-05Rollup merge of #67011 - Aaron1011:fix/expected-found-span, r=Dylan-DPCMazdak Farrokhzad-18/+48
Include a span in more `expected...found` notes In most places, we use a span when emitting `expected...found` errors. However, there were a couple of places where we didn't use any span, resulting in hard-to-interpret error messages. This commit attaches the relevant span to these notes, and additionally switches over to using `note_expected_found` instead of manually formatting the message
2019-12-05Rollup merge of #67010 - estebank:raw-idents, r=CentrilMazdak Farrokhzad-0/+44
Accurately portray raw identifiers in error messages When refering to or suggesting raw identifiers, refer to them with `r#`. Fix #65634.
2019-12-05Rollup merge of #66863 - osa1:fix_66702, r=cramertjMazdak Farrokhzad-0/+18
Check break target availability when checking breaks with values Fixes #66702 I'll be adding a regression test.
2019-12-05Add UI test for Pin PartialEq unsoundnessKonrad Borowski-0/+40
2019-12-05E0023: handle expected != pat-tup-typeMazdak Farrokhzad-0/+43
2019-12-04Forgot to update some test outputsNadrieril-2/+2
2019-12-03review comments: move testEsteban Küber-0/+44
2019-12-03Include a span in more `expected...found` notesAaron Hill-18/+48
In most places, we use a span when emitting `expected...found` errors. However, there were a couple of places where we didn't use any span, resulting in hard-to-interpret error messages. This commit attaches the relevant span to these notes, and additionally switches over to using `note_expected_found` instead of manually formatting the message
2019-12-03Disable issue-59756 test for nowAaron Hill-0/+4
Currently, rustfix has no notion of mutually exclusive suggestions. When it processes issue-59756, it will attempt to apply two mutually exclusive suggestions for the same span, causing an error.
2019-12-03Emit coercion suggestions in more placesAaron Hill-8/+18
Fixes #66910 We have several different kinds of suggestions we can try to make when type coercion fails. However, we were previously only emitting these suggestions from `demand_coerce_diag`. This resulted in the compiler failing to emit applicable suggestions in several different cases, such as when the implicit return value of a function had the wrong type. This commit adds a new `emit_coerce_suggestions` method, which tries to emit a number of related suggestions. This method is called from both `demand_coerce_diag` and `CoerceMany::coerce_inner`, which covers a much wider range of cases than before. We now suggest using `.await` in more cases where it is applicable, among other improvements.
2019-12-03Check break target availability when checking breaks with valuesÖmer Sinan Ağacan-0/+18
Fixes #66702
2019-12-02Add long error for E0631 and update ui tests.Reese Williams-2/+4
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 04:57:49 +0000