summary refs log tree commit diff
path: root/src/test/ui/const-generics/issues
AgeCommit message (Collapse)AuthorLines
2022-07-27Rollup merge of #99651 - compiler-errors:fn-and-raw-ptr-in-const-generics, ↵Guillaume Gomez-7/+44
r=oli-obk Deeply deny fn and raw ptrs in const generics I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter. We now reject both of these in the same way: ``` #![feature(adt_const_params)] #[derive(Eq, PartialEq)] struct Wrapper(); fn foo<const W: Wrapper>() {} fn foo2<const F: fn()>() {} ``` This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place. cc: ``@b-naber`` who introduced that test^ fixes #99641
2022-07-26Fix diagnostics for unfulfilled obligationsDeadbeef-2/+0
2022-07-26bless tests, remove nonexistent E0395Deadbeef-44/+20
2022-07-25Deeply deny fn and raw ptrs in const genericsMichael Goulet-7/+44
2022-07-22Do not resolve associated const when there is no provided valueMichael Goulet-18/+28
2022-07-20Add regression test for #71547Yuki Okushi-0/+18
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
2022-07-01Shorten def_span for more items.Camille GILLOT-1/+1
2022-06-25Rollup merge of #98429 - b-naber:use-correct-substs-discriminant-cast, r=lcnrMatthias Krüger-0/+10
Use correct substs in enum discriminant cast Fixes https://github.com/rust-lang/rust/issues/97634 r? ```@lcnr```
2022-06-24fmtb-naber-1/+1
2022-06-24add testb-naber-0/+10
2022-06-21Add a full regression test for #73727Yuki Okushi-0/+25
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
2022-06-14implement valtrees as the type-system representation for constant valuesb-naber-1/+5
2022-06-13Add some more regression tests for #67945Yuki Okushi-0/+107
2022-06-02add new `emit_inference_failure_err`lcnr-8/+5
2022-05-24add and update testsb-naber-2/+25
2022-05-20Rollup merge of #97109 - ↵Matthias Krüger-0/+6
TaKO8Ki:fix-misleading-cannot-infer-type-for-type-parameter-error, r=oli-obk Fix misleading `cannot infer type for type parameter` error closes #93198
2022-05-20report ambiguous type parameters when their parents are impl or fnTakayuki Maeda-0/+6
fix ci error emit err for `impl_item`
2022-05-19Add regression test for #88119Yuki Okushi-0/+35
2022-05-11Gracefully fail to resolve associated items instead of `delay_span_bug`.Camille GILLOT-1/+18
2022-05-11Rollup merge of #96717 - BoxyUwU:gats_const_param_types_mismatch_err, r=lcnrYuki Okushi-15/+15
Handle mismatched generic param kinds in trait impls betterly - Check that generic params on a generic associated type are the same as in the trait definition - Check that const generics are not used in place of type generics (and the other way round too) r? `@lcnr`
2022-05-08Correct the issue number of a testYuki Okushi-1/+1
2022-05-08Add regression test for #96654Yuki Okushi-0/+15
2022-05-06wording tweaksEllen-4/+4
2022-05-05 make `compare_generic_param_kinds` errors consistentEllen-15/+15
2022-05-01Enable full revision in const generics ui testsAlex Macleod-0/+36
2022-04-30Auto merge of #95776 - cjgillot:ast-lifetimes-static, r=petrochenkovbors-1/+11
Enforce static lifetimes in consts during late resolution This PR moves the handling of implicitly and explicitly static lifetimes in constants from HIR to the AST.
2022-04-29Bless tests.Camille GILLOT-1/+11
2022-04-28Update the diagnostic message to match the new spanOli Scherer-2/+2
2022-04-28Check that repeat expression elements are Copy (ignoring lifetimes) in ↵Oli Scherer-4/+4
typeck and that they are Copy (with proper lifetime checks) in borrowck
2022-04-17show suggestion to replace generic bounds with associated types in more casesRobin Appelman-1/+1
2022-04-11simplify const params diagnostic on stableOliver Downard-9/+2
2022-04-05Rollup merge of #95654 - notriddle:notriddle/issue-95616, r=davidtwcoDylan DPC-12/+12
diagnostics: use correct span for const generics Fixes #95616
2022-04-04Dedup logic and improve output for other types that impl traitEsteban Kuber-18/+18
2022-04-04diagnostics: use correct span for const genericsMichael Howell-12/+12
Fixes #95616
2022-03-22fix previous failures and address reviewb-naber-58/+70
2022-03-21add/update testsb-naber-137/+13
2022-03-07Update tests after feature stabilizationEric Holk-1/+1
2022-03-03Cleanup feature gates.Camille GILLOT-1/+1
2022-02-20Gracefully handle non-UTF-8 string slices when pretty printingTomasz Miąsko-16/+0
2022-02-12Rebased and improved errorsDeadbeef-4/+20
2022-01-18Rollup merge of #92780 - b-naber:postpone-const-eval-coherence, r=lcnrMatthias Krüger-0/+12
Directly use ConstValue for single literals in blocks Addresses the minimal repro in https://github.com/rust-lang/rust/issues/92186, but doesn't fix the underlying problem (which would be solved by solving the anon subst problem afaict). I do, however, think that it makes sense in general to treat single literals in anon blocks as const values directly, especially in light of the problem that the issue refers to (anon const evaluation being postponed until infer variables in substs can be resolved, which was introduced by https://github.com/rust-lang/rust/pull/90023), i.e. while we do get warnings for those unnecessary braces, we should try to avoid errors caused by those braces if possible.
2022-01-17add and update testsb-naber-0/+12
2022-01-14fix bugEllen-11/+3
2021-12-10Rollup merge of #91678 - b-naber:tests-for-postpone-const-eval, r=jackh726Matthias Krüger-0/+387
Add tests fixed by #90023 The following issues were fixed by https://github.com/rust-lang/rust/pull/90023 Fixes https://github.com/rust-lang/rust/issues/79674 Fixes https://github.com/rust-lang/rust/issues/83765 Fixes https://github.com/rust-lang/rust/issues/86033 Fixes https://github.com/rust-lang/rust/issues/90318 Fixes https://github.com/rust-lang/rust/issues/88468 The following issues were duplicates of https://github.com/rust-lang/rust/issues/90654 Fixes https://github.com/rust-lang/rust/issues/86850 Fixes https://github.com/rust-lang/rust/issues/89022 r? ````@jackh726````
2021-12-08add testsb-naber-0/+387
2021-12-08Rollup merge of #91551 - b-naber:const-eval-normalization-ice, r=oli-obkMatthias Krüger-0/+61
Allow for failure of subst_normalize_erasing_regions in const_eval Fixes https://github.com/rust-lang/rust/issues/72845 Using associated types that cannot be normalized previously resulted in an ICE. We now allow for normalization failure and return a "TooGeneric" error in that case. r? ```@RalfJung``` maybe?
2021-12-05Rollup merge of #90529 - b-naber:reborrows-consts, r=lcnrMatthias Krüger-0/+22
Skip reborrows in AbstractConstBuilder Fixes https://github.com/rust-lang/rust/issues/90455 Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions. r? `@oli-obk`
2021-12-05add test and bless existing onesb-naber-0/+61
2021-12-05add testb-naber-0/+22
2021-12-05Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars, r=nikomatsakisMatthias Krüger-0/+201
Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected, hence no real error was ever encountered, but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants, so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?