summary refs log tree commit diff
path: root/src/test/ui/issues
AgeCommit message (Collapse)AuthorLines
2020-07-30Add a test for pattern matching within a tupleMark Rousskov-0/+7
2020-07-30Revert "Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern"Mark Rousskov-33/+0
This reverts commit 174b58287c66a6ad3eaa1897279d769611919960.
2020-07-23Fix an ICE on an invalid `binding @ ...` in a tuple struct patternJakub Adam Wieczorek-0/+33
2020-07-10Perform obligation deduplication to avoid buggy `ExistentialMismatch`Esteban Küber-0/+26
Fix #59326.
2020-06-26Beta backport of PR #73005 (obligation error impl candidate)Aaron Hill-0/+28
2020-06-26Ensure stack when building MIR for matchesSimonas Kazlauskas-0/+5208
In particular matching on complex types such as strings will cause deep recursion to happen. Fixes #72933
2020-05-31Add descriptions for all queriesMatthew Jasper-4/+4
2020-05-30Rollup merge of #72625 - Amanieu:asm-srcloc, r=petrochenkovRalf Jung-6/+9
Improve inline asm error diagnostics Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics. The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code. Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate. Fixes #72664 Fixes #71639 r? @petrochenkov ### Old style ```rust #![feature(llvm_asm)] fn main() { unsafe { let _x: i32; llvm_asm!( "mov $0, $1 invalid_instruction $0, $1 mov $0, $1" : "=&r" (_x) : "r" (0) :: "intel" ); } } ``` ``` error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction' invalid_instruction ecx, eax ^~~~~~~~~~~~~~~~~~~ --> src/main.rs:6:9 | 6 | / llvm_asm!( 7 | | "mov $0, $1 8 | | invalid_instruction $0, $1 9 | | mov $0, $1" ... | 12 | | :: "intel" 13 | | ); | |__________^ ``` ### New style ```rust #![feature(asm)] fn main() { unsafe { asm!( "mov {0}, {1} invalid_instruction {0}, {1} mov {0}, {1}", out(reg) _, in(reg) 0i64, ); } } ``` ``` error: invalid instruction mnemonic 'invalid_instruction' --> test.rs:7:14 | 7 | invalid_instruction {0}, {1} | ^ | note: instantiated into assembly here --> <inline asm>:3:14 | 3 | invalid_instruction rax, rcx | ^^^^^^^^^^^^^^^^^^^ ```
2020-05-30Tweak wording and spans of `'static` `dyn Trait`/`impl Trait` requirementsEsteban Küber-11/+5
2020-05-30Update nll testsEsteban Küber-0/+10
2020-05-30review comment: tweak wording and account for span overlapEsteban Küber-1/+1
2020-05-30Account for returned `dyn Trait` evaluating to `'static` lifetimeEsteban Küber-7/+20
Provide a suggestion for `dyn Trait + '_` when possible.
2020-05-30Rollup merge of #72540 - davidtwco:issue-67552-mono-collector-comparison, ↵Ralf Jung-8/+55
r=varkor mir: adjust conditional in recursion limit check Fixes #67552. This PR adjusts the condition used in the recursion limit check of the monomorphization collector, from `>` to `>=`. In #67552, the test case had infinite indirect recursion, repeating a handful of functions (from the perspective of the monomorphization collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold` -> `Iterator::next` -> `rec`. During this process, `resolve_associated_item` was invoked for `Iterator::fold` (during the construction of an `Instance`), and ICE'd due to substitutions needing inference. However, previous iterations of this recursion would have called this function for `Iterator::fold` - and did! - and succeeded in doing so (trivially checkable from debug logging, `()` is present where `_` is in the substs of the failing execution). The expected outcome of this test case would be a recursion limit error (which is present when the `identity` fn indirection is removed), and the recursion depth of `rec` is increasing (other functions finish collecting their neighbours and thus have their recursion depths reset). When the ICE occurs, the recursion depth of `rec` is 256 (which matches the recursion limit), which suggests perhaps that a different part of the compiler is using a `>=` comparison and returning a different result on this recursion rather than what it returned in every previous recursion, thus stopping the monomorphization collector from reporting an error on the next recursion, where `recursion_depth_of_rec > 256` would have been true. With grep and some educated guesses, we can determine that the recursion limit check at line 818 in `src/librustc_trait_selection/traits/project.rs` is the other check that is using a different comparison. Modifying either comparison to be `>` or `>=` respectively will fix the error, but changing the monomorphization collector produces the nicer error.
2020-05-30Rollup merge of #72441 - doctorn:late-bound-lifetime-ice, r=nikomatsakisRalf Jung-0/+34
Fix ICE with explicit late-bound lifetimes Rather than returning an explicit late-bound lifetime as a generic argument count mismatch (which is not necessarily true), this PR propagates the presence of explicit late-bound lifetimes. This avoids an ICE that can occur due to the presence of explicit late-bound lifetimes when building generic substitutions by explicitly ignoring them. r? @varkor cc @davidtwco (this removes a check you introduced in #60892) Resolves #72278
2020-05-30Rollup merge of #72677 - chrissimpkins:fix-72574, r=estebankYuki Okushi-0/+46
Fix diagnostics for `@ ..` binding pattern in tuples and tuple structs Fixes #72574 Associated https://github.com/rust-lang/rust/pull/72534 https://github.com/rust-lang/rust/issues/72373 Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level. ### Before #### tuple ``` error: `..` patterns are not allowed here --> src/main.rs:4:19 | 4 | (_a, _x @ ..) => {} | ^^ | = note: only allowed in tuple, tuple struct, and slice patterns error[E0308]: mismatched types --> src/main.rs:4:9 | 3 | match x { | - this expression has type `({integer}, {integer}, {integer})` 4 | (_a, _x @ ..) => {} | ^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 2 elements | = note: expected tuple `({integer}, {integer}, {integer})` found tuple `(_, _)` error: aborting due to 2 previous errors ``` #### tuple struct ``` error: `..` patterns are not allowed here --> src/main.rs:6:25 | 6 | Binder(_a, _x @ ..) => {} | ^^ | = note: only allowed in tuple, tuple struct, and slice patterns error[E0023]: this pattern has 2 fields, but the corresponding tuple struct has 3 fields --> src/main.rs:6:9 | 1 | struct Binder(i32, i32, i32); | ----------------------------- tuple struct defined here ... 6 | Binder(_a, _x @ ..) => {} | ^^^^^^^^^^^^^^^^^^^ expected 3 fields, found 2 error: aborting due to 2 previous errors ``` ### After *Note: final output edited during source review discussion, see thread for details* #### tuple ``` error: `_x @` is not allowed in a tuple --> src/main.rs:4:14 | 4 | (_a, _x @ ..) => {} | ^^^^^^^ is only allowed in a slice | help: replace with `..` or use a different valid pattern | 4 | (_a, ..) => {} | ^^ error[E0308]: mismatched types --> src/main.rs:4:9 | 3 | match x { | - this expression has type `({integer}, {integer}, {integer})` 4 | (_a, _x @ ..) => {} | ^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 1 element | = note: expected tuple `({integer}, {integer}, {integer})` found tuple `(_,)` error: aborting due to 2 previous errors ``` #### tuple struct ``` error: `_x @` is not allowed in a tuple struct --> src/main.rs:6:20 | 6 | Binder(_a, _x @ ..) => {} | ^^^^^^^ is only allowed in a slice | help: replace with `..` or use a different valid pattern | 6 | Binder(_a, ..) => {} | ^^ error[E0023]: this pattern has 1 field, but the corresponding tuple struct has 3 fields --> src/main.rs:6:9 | 1 | struct Binder(i32, i32, i32); | ----------------------------- tuple struct defined here ... 6 | Binder(_a, _x @ ..) => {} | ^^^^^^^^^^^^^^^^^^^ expected 3 fields, found 1 error: aborting due to 2 previous errors ``` r? @estebank
2020-05-29Auto merge of #72756 - RalfJung:rollup-tbjmtx2, r=RalfJungbors-14/+14
Rollup of 9 pull requests Successful merges: - #67460 (Tweak impl signature mismatch errors involving `RegionKind::ReVar` lifetimes) - #71095 (impl From<[T; N]> for Box<[T]>) - #71500 (Make pointer offset methods/intrinsics const) - #71804 (linker: Support `-static-pie` and `-static -shared`) - #71862 (Implement RFC 2585: unsafe blocks in unsafe fn) - #72103 (borrowck `DefId` -> `LocalDefId`) - #72407 (Various minor improvements to Ipv6Addr::Display) - #72413 (impl Step for char (make Range*<char> iterable)) - #72439 (NVPTX support for new asm!) Failed merges: r? @ghost
2020-05-29fix diagnostics for `@ ..` binding pattern in tuples and tuple structsChris Simpkins-0/+46
fix comment add newline for tidy fmt error... edit suggestion message change the suggestion message to better handle cases with binding modes Apply suggestions from estebank code review Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com> edits to address source review Apply suggestions from estebank code review #2 Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com> update test files
2020-05-29Rollup merge of #67460 - estebank:named-lts, r=nikomatsakisRalf Jung-14/+14
Tweak impl signature mismatch errors involving `RegionKind::ReVar` lifetimes Fix #66406, fix #72106. ``` error: `impl` item signature doesn't match `trait` item signature --> $DIR/trait-param-without-lifetime-constraint.rs:14:5 | LL | fn get_relation(&self) -> To; | ----------------------------- expected `fn(&Article) -> &ProofReader` ... LL | fn get_relation(&self) -> &ProofReader { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&Article) -> &ProofReader` | = note: expected `fn(&Article) -> &ProofReader` found `fn(&Article) -> &ProofReader` help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait` --> $DIR/trait-param-without-lifetime-constraint.rs:10:31 | LL | fn get_relation(&self) -> To; | ^^ consider borrowing this type parameter in the trait ``` r? @nikomatsakis
2020-05-29Improve inline asm error diagnosticsAmanieu d'Antras-6/+9
2020-05-29liveness: Warn about unused captured variablesTomasz Miąsko-1/+22
2020-05-28Fix ICE with explicit late-bound lifetimesNathan Corbyn-0/+34
2020-05-28standardize limit comparisons with `Limit` typeDavid Wood-10/+13
This commit introduces a `Limit` type which is used to ensure that all comparisons against limits within the compiler are consistent (which can result in ICEs if they aren't). Signed-off-by: David Wood <david@davidtw.co>
2020-05-28mir: adjust conditional in recursion limit checkDavid Wood-1/+45
This commit adjusts the condition used in the recursion limit check of the monomorphization collector, from `>` to `>=`. In #67552, the test case had infinite indirect recursion, repeating a handful of functions (from the perspective of the monomorphization collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold` -> `Iterator::next` -> `rec`. During this process, `resolve_associated_item` was invoked for `Iterator::fold` (during the construction of an `Instance`), and ICE'd due to substitutions needing inference. However, previous iterations of this recursion would have called this function for `Iterator::fold` - and did! - and succeeded in doing so (trivially checkable from debug logging, `()` is present where `_` is in the substs of the failing execution). The expected outcome of this test case would be a recursion limit error (which is present when the `identity` fn indirection is removed), and the recursion depth of `rec` is increasing (other functions finish collecting their neighbours and thus have their recursion depths reset). When the ICE occurs, the recursion depth of `rec` is 256 (which matches the recursion limit), which suggests perhaps that a different part of the compiler is using a `>=` comparison and returning a different result on this recursion rather than what it returned in every previous recursion, thus stopping the monomorphization collector from reporting an error on the next recursion, where `recursion_depth_of_rec > 256` would have been true. With grep and some educated guesses, we can determine that the recursion limit check at line 818 in `src/librustc_trait_selection/traits/project.rs` is the other check that is using a different comparison. Modifying either comparison to be `>` or `>=` respectively will fix the error, but changing the monomorphization collector produces the nicer error. Signed-off-by: David Wood <david@davidtw.co>
2020-05-27Fix rebaseEsteban Küber-4/+0
2020-05-27fix rebaseEsteban Küber-2/+2
2020-05-27Tweak output for mismatched impl itemEsteban Küber-7/+7
Detect type parameter that might require lifetime constraint. Do not name `ReVar`s in expected/found output. Reword text suggesting to check the lifetimes.
2020-05-27Name `RegionKind::ReVar` lifetimes in diagnosticsEsteban Küber-7/+11
2020-05-27Fix spacing of expected/found notes without a labelEsteban Küber-12/+12
2020-05-27improve diagnostics suggestion for missing `@` in slice id binding to rest ↵Chris Simpkins-0/+22
pattern add issue 72373 tests fmt test fix suggestion format Replacement, not insertion of suggested string implement review changes refactor to span_suggestion_verbose, improve suggestion message, change id @ pattern space formatting fmt fix diagnostics spacing between ident and @ refactor reference
2020-05-27Rollup merge of #72548 - rossmacarthur:add-mcve-for-50687, r=nikomatsakisDylan DPC-0/+57
Add test for old compiler ICE when using `Borrow` The original issue was caused by implementing `Borrow` on a local type and using the tokio-reactor crate which had this impl: https://github.com/tokio-rs/tokio/blob/tokio-0.1.4/tokio-reactor/src/poll_evented.rs#L547-L577 This causes an ICE on Rust 1.27.0: ```console $ RUSTUP_TOOLCHAIN=1.27.0 rustc src/test/ui/issues/issue-50687-ice-on-borrow.rs error: internal compiler error: librustc/traits/structural_impls.rs:180: impossible case reached thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:554:9 note: Run with `RUST_BACKTRACE=1` for a backtrace. error: aborting due to previous error note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports note: rustc 1.27.0 (3eda71b00 2018-06-19) running on x86_64-apple-darwin ``` Closes #50687
2020-05-27Rollup merge of #72348 - chrissimpkins:fix-72253, r=estebankDylan DPC-0/+16
Fix confusing error message for comma typo in multiline statement Fixes #72253. Expands on the issue with a colon typo check. r? @estebank cc @ehuss
2020-05-26improve error message for unexpected comma token in multiline blockChris Simpkins-0/+16
confusing diagnostics, issue #72253 add test for confusing error message, issue-72253 remove is_multiline check, refactor to self.expect(&token:Semi) update issue-72253 tests return Ok
2020-05-26Rollup merge of #72270 - RalfJung:lint-ref-to-packed, r=oli-obkDylan DPC-18/+4
add a lint against references to packed fields Creating a reference to an insufficiently aligned packed field is UB and should be disallowed, both inside and outside of `unsafe` blocks. However, currently there is no stable alternative (https://github.com/rust-lang/rust/issues/64490) so all we do right now is have a future incompatibility warning when doing this outside `unsafe` (https://github.com/rust-lang/rust/issues/46043). This adds an allow-by-default lint. @retep998 suggested this can help early adopters avoid issues. It also means we can then do a crater run where this is deny-by-default as suggested by @joshtriplett. I guess the main thing to bikeshed is the lint name. I am not particularly happy with "packed_references" as it sounds like the packed field has reference type. I chose this because it is similar to "safe_packed_borrows". What about "reference_to_packed" or "unaligned_reference" or so?
2020-05-25Auto merge of #72354 - tamird:remove-copyright, r=Mark-Simulacrumbors-2/+0
Remove dangling COPYRIGHT references Missed in 2a663555ddf36f6b041445894a8c175cd1bc718c. r? @Mark-Simulacrum
2020-05-25remove some unused types from the testsRalf Jung-18/+4
2020-05-25Add test for old compiler ICE when using `Borrow`Ross MacArthur-0/+57
2020-05-23Add test for #72455Yuki Okushi-0/+27
2020-05-21Rollup merge of #72149 - estebank:icemation, r=eddybRalf Jung-0/+20
Don't `type_of` on trait assoc ty without default Fix #72076.
2020-05-19Alter wording for `use foo::self` helpmibac138-2/+2
2020-05-19Add error recovery for `use foo::self`mibac138-2/+17
2020-05-19Suggest fixes for `use foo::self`mibac138-2/+11
2020-05-19Remove dangling COPYRIGHT referencesTamir Duberstein-2/+0
Missed in 2a663555ddf36f6b041445894a8c175cd1bc718c.
2020-05-19Rollup merge of #72068 - estebank:mut-deref-hack, r=oli-obkDylan DPC-0/+29
Ignore arguments when looking for `IndexMut` for subsequent `mut` obligation Given code like `v[&field].boo();` where `field: String` and `.boo(&mut self)`, typeck will have decided that `v` is accessed using `Index`, but when `boo` adds a new `mut` obligation, `convert_place_op_to_mutable` is called. When this happens, for *some reason* the arguments' dereference adjustments are completely ignored causing an error saying that `IndexMut` is not satisfied: ``` error[E0596]: cannot borrow data in an index of `Indexable` as mutable --> src/main.rs:30:5 | 30 | v[&field].boo(); | ^^^^^^^^^ cannot borrow as mutable | = help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Indexable` ``` This is not true, but by changing `try_overloaded_place_op` to retry when given `Needs::MutPlace` without passing the argument types, the example successfully compiles. I believe there might be more appropriate ways to deal with this. Fix #72002.
2020-05-18Rollup merge of #71599 - ldm0:fnclo, r=nikomatsakisDylan DPC-18/+7
Support coercion between (FnDef | Closure) and (FnDef | Closure) Fixes #46742, fixes #48109 Inject `Closure` into the `FnDef x FnDef` coercion special case, which makes coercion of `(FnDef | Closure) x (FnDef | Closure)` possible, where closures should be **non-capturing**.
2020-05-16Rollup merge of #72045 - RalfJung:incomplete-unsound, r=petrochenkovRalf Jung-2/+3
Incomplete features can also be unsound Some incomplete features do not just ICE, they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029, and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that. While at it I also added a link to the tracking issue, which hopefully should explain what is incomplete/unsound about the feature.
2020-05-14Don't ICE on missing `Unsize` implNathan Corbyn-0/+29
2020-05-12fix test output after rebaseEsteban Küber-1/+1
2020-05-12Increase verbosity of bound restriction suggestionsEsteban Küber-8/+14
- Make the bound restriction suggestion `span_suggestion_verbose`. - Fix whitespace typo.
2020-05-12Don't `type_of` on trait assoc ty without defaultEsteban Küber-0/+20
Fix #72076.
2020-05-11Ignore arguments when looking for `IndexMut` for subsequent `mut` obligationEsteban Küber-0/+29
Given code like `v[&field].boo();` where `field: String` and `.boo(&mut self)`, typeck will have decided that `v` is accessed using `Index`, but when `boo` adds a new `mut` obligation, `convert_place_op_to_mutable` is called. When this happens, for *some reason* the arguments' dereference adjustments are completely ignored causing an error saying that `IndexMut` is not satisfied: ``` error[E0596]: cannot borrow data in an index of `Indexable` as mutable --> src/main.rs:30:5 | 30 | v[&field].boo(); | ^^^^^^^^^ cannot borrow as mutable | = help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Indexable` ``` This is not true, but by changing `try_overloaded_place_op` to retry when given `Needs::MutPlace` without passing the argument types, the example successfully compiles. I believe there might be more appropriate ways to deal with this.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-03 22:12:01 +0000