about summary refs log tree commit diff
path: root/src/test/ui/generator
AgeCommit message (Collapse)AuthorLines
2021-03-20Move some tests to more reasonable directories - 5Caio-0/+20
2021-03-15Only allow tait defining uses in function and method return positionOli Scherer-11/+75
2021-03-15Replace `type_alias_impl_trait` by `min_type_alias_impl_trait` with no ↵Oli Scherer-3/+56
actual changes in behaviour This makes `type_alias_impl_trait` not actually do anything anymore
2021-03-12Make def_key and HIR parenting consistent.Camille GILLOT-5/+5
2021-02-19Rollup merge of #82245 - estebank:issue-78653, r=matthewjasperDylan DPC-0/+28
Do not ICE when evaluating locals' types of invalid `yield` When a `yield` is outside of a generator, check its value regardless to avoid an ICE while trying to get all locals' types in writeback. Fix #78653.
2021-02-17Do not ICE when evaluating locals' types of invalid `yield`Esteban Küber-0/+28
When a `yield` is outside of a generator, check its value regardless to avoid an ICE while trying to get all locals' types in writeback. Fix #78653.
2021-02-10Keep existing names of regions in placeholder_errorMatthew Jasper-4/+4
2021-02-09Remove unnecessary note on errorsMatthew Jasper-12/+0
Seeing the trait definition doesn't help with implementation not general enough errors, so don't make the error message larger to show it.
2021-02-06path trimming: ignore type aliasesDan Aloni-5/+5
2021-02-01Update ui testsJesus Rubio-0/+1
2021-01-15Rollup merge of #81008 - tmiasko:generator-layout-err, r=tmandryYuki Okushi-0/+37
Don't ICE when computing a layout of a generator tainted by errors Fixes #80998.
2021-01-14Don't ICE when computing a layout of a generator tainted by errorsTomasz Miąsko-0/+37
2021-01-14Encode optimized MIR of generators when emitting metadataTomasz Miąsko-0/+34
2021-01-12Provide more information for HRTB lifetime errors involving closuresEsteban Küber-2/+30
2020-12-06Add a few basic tests for if-let guardsLeSeulArtichaut-0/+11
2020-11-23Rename `optin_builtin_traits` to `auto_traits`Camelid-1/+1
They were originally called "opt-in, built-in traits" (OIBITs), but people realized that the name was too confusing and a mouthful, and so they were renamed to just "auto traits". The feature flag's name wasn't updated, though, so that's what this PR does. There are some other spots in the compiler that still refer to OIBITs, but I don't think changing those now is worth it since they are internal and not particularly relevant to this PR. Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
2020-11-10Use Places to express closure/generator CapturesAman Arora-2/+2
Co-authored-by: Archer Zhang <archer.xn@gmail.com>
2020-10-26always record reference to binding in match if guardsSNCPlay42-1/+20
2020-10-22Explain where the closure return type was inferredAaron Hill-0/+5
Fixes #78193
2020-10-15Auto merge of #77873 - sexxi-goose:use_tuple_inference_for_closures, ↵bors-7/+7
r=nikomatsakis Replace tuple of infer vars for upvar_tys with single infer var This commit allows us to decide the number of captures required after completing capture ananysis, which is required as part of implementing RFC-2229. closes https://github.com/rust-lang/project-rfc-2229/issues/4 r? `@nikomatsakis`
2020-10-14switch the test to an actual MCVEDing Xiang Fei-14/+9
2020-10-14rustfmtDing Xiang Fei-1/+1
2020-10-14test derived from #74961Ding Xiang Fei-0/+29
2020-10-11traits diagnostics: Don't print closure/generator upvar_tys tupleAman Arora-4/+0
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
2020-10-11Always return tupled_upvar_tys for Closure/Generator consituent tysAman Arora-0/+2
Depending on if upvar_tys inferred or not, we were returning either an inference variable which later resolves to a tuple or else the upvar tys themselves Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
2020-10-11Replace tuple of infer vars for upvar_tys with single infer varRoxane-7/+9
This commit allows us to decide the number of captures required after completing capture ananysis, which is required as part of implementing RFC-2229. Co-authored-by: Aman Arora <me@aman-arora.com> Co-authored-by: Jenny Wills <wills.jenniferg@gmail.com>
2020-10-06Fix tests from rebaseMatthew Jasper-1/+1
2020-10-06Fix rebaseMatthew Jasper-1/+1
2020-10-06Check opaque types satisfy their boundsMatthew Jasper-1/+0
2020-10-06Separate bounds and predicates for associated/opaque typesMatthew Jasper-0/+5
2020-09-28Add tests for updated closure/generator printingAman Arora-0/+191
Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com> Co-authored-by: Logan Mosier <logmosier@gmail.com>
2020-09-28pretty.rs: Update Closure and Generator printAman Arora-2/+2
Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com> Co-authored-by: Logan Mosier <logmosier@gmail.com>
2020-09-08Capitalize safety commentsFlying-Toast-1/+1
2020-09-02pretty: trim paths of unique symbolsDan Aloni-31/+31
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-28Make closures and generators a must use typesTomasz Miąsko-10/+163
Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce`, `FnMut`, `Fn` traits, which already indirectly apply to closures in some cases, e.g.,: ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ```
2020-07-15improve DiscriminantKind handlingBastian Kauschke-2/+2
This now reuses `fn discriminant_ty` in project, removing some code duplication. Doing so made me realize that we previously had a disagreement about the discriminant type of generators, with MIR using `u32` and codegen and trait selection using `i32`. We now always use `u32`.
2020-07-14Remove `Sized` `on_unimplemented` noteEsteban Küber-2/+0
2020-06-22fix subtle bug in NLL type checkerNiko Matsakis-0/+8
The bug was revealed by the behavior of the old-lub-glb-hr-noteq1.rs test. The old-lub-glb-hr-noteq2 test shows the current 'order dependent' behavior of coercions around higher-ranked functions, at least when running with `-Zborrowck=mir`. Also, run compare-mode=nll.
2020-06-22move leak-check to during coherence, candidate evalNiko Matsakis-12/+19
In particular, it no longer occurs during the subtyping check. This is important for enabling lazy normalization, because the subtyping check will be producing sub-obligations that could affect its results. Consider an example like for<'a> fn(<&'a as Mirror>::Item) = fn(&'b u8) where `<T as Mirror>::Item = T` for all `T`. We will wish to produce a new subobligation like <'!1 as Mirror>::Item = &'b u8 This will, after being solved, ultimately yield a constraint that `'!1 = 'b` which will fail. But with the leak-check being performed on subtyping, there is no opportunity to normalize `<'!1 as Mirror>::Item` (unless we invoke that normalization directly from within subtyping, and I would prefer that subtyping and unification are distinct operations rather than part of the trait solving stack). The reason to keep the leak check during coherence and trait evaluation is partly for backwards compatibility. The coherence change permits impls for `fn(T)` and `fn(&T)` to co-exist, and the trait evaluation change means that we can distinguish those two cases without ambiguity errors. It also avoids recreating #57639, where we were incorrectly choosing a where clause that would have failed the leak check over the impl which succeeds. The other reason to keep the leak check in those places is that I think it is actually close to the model we want. To the point, I think the trait solver ought to have the job of "breaking down" higher-ranked region obligation like ``!1: '2` into into region obligations that operate on things in the root universe, at which point they should be handed off to polonius. The leak check isn't *really* doing that -- these obligations are still handed to the region solver to process -- but if/when we do adopt that model, the decision to pass/fail would be happening in roughly this part of the code. This change had somewhat more side-effects than I anticipated. It seems like there are cases where the leak-check was not being enforced during method proving and trait selection. I haven't quite tracked this down but I think it ought to be documented, so that we know what precisely we are committing to. One surprising test was `issue-30786.rs`. The behavior there seems a bit "fishy" to me, but the problem is not related to the leak check change as far as I can tell, but more to do with the closure signature inference code and perhaps the associated type projection, which together seem to be conspiring to produce an unexpected signature. Nonetheless, it is an example of where changing the leak-check can have some unexpected consequences: we're now failing to resolve a method earlier than we were, which suggests we might change some method resolutions that would have been ambiguous to be successful. TODO: * figure out remainig test failures * add new coherence tests for the patterns we ARE disallowing
2020-06-08Revert #71956Dylan MacKenzie-1/+1
2020-05-27Fix incorrect comment in generator testJonas Schievink-1/+1
2020-05-22Auto merge of #71956 - ecstatic-morse:remove-requires-storage-analysis, ↵bors-1/+1
r=tmandry Clean up logic around live locals in generator analysis Resolves #69902. Requires #71893. I've found it difficult to make changes in the logic around live locals in `generator/transform.rs`. It uses a custom dataflow analysis, `MaybeRequiresStorage`, that AFAICT computes whether a local is either initialized or borrowed. That analysis is using `before` effects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday. This PR replaces `MaybeRequiresStorage` with a combination of the existing `MaybeBorrowedLocals` and a new `MaybeInitializedLocals`. `MaybeInitializedLocals` is just `MaybeInitializedPlaces` with a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic in `compute_storage_conflicts` and `locals_live_across_suspend_points`. This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the `mixed_sizes` future couldn't be 5K. It went from 7K to 6K in this PR. r? @jonas-schievink @tmandry
2020-05-19Update tests with new generator sizesDylan MacKenzie-1/+1
2020-05-19update `discriminant_value` usage in testsBastian Kauschke-3/+6
2020-05-08Skip tests on emscriptenYuki Okushi-0/+1
2020-05-06Move tests from `test/run-fail` to UIYuki Okushi-0/+23
2020-04-28also run some generator tests without MIR optimizationsRalf Jung-0/+15
2020-04-19Auto merge of #70015 - jonas-schievink:gen-needs-drop, r=matthewjasperbors-13/+9
Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of https://github.com/rust-lang/rust/pull/69814 since that contains some fixes that are made relevant by *this* PR (see https://github.com/rust-lang/rust/pull/69814#issuecomment-599147269).~~ (this has been merged)
2020-04-18Add label to item source of bound obligationEsteban Küber-2/+2
2020-04-17Make `needs_drop` less pessimistic on generatorsJonas Schievink-13/+9
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 12:11:03 +0000