summary refs log tree commit diff
path: root/src/test/ui/generator
AgeCommit message (Collapse)AuthorLines
2020-06-13Revert "Auto merge of #71956 - ↵Mark Rousskov-1/+1
ecstatic-morse:remove-requires-storage-analysis, r=tmandry" This reverts commit 458a3e76294fd859fb037f425404180c91e14767, reversing changes made to d9417b385145af1cabd0be8a95c65075d2fc30ff.
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
2020-04-13Update test after rebaseTyler Mandry-2/+2
2020-04-13Incorporate feedback into diagnosticsTyler Mandry-4/+4
2020-04-13Use "generator" instead of "future" when appropriateTyler Mandry-6/+6
2020-04-13Don't annotate type when type is opaqueTyler Mandry-1/+1
2020-04-13Improve span labelTyler Mandry-2/+2
2020-04-13Add test for #68112 (existing output)Tyler Mandry-0/+96
2020-04-08Small tweaks to required bound spanEsteban Küber-4/+4
2020-03-26introduce `negative_impls` feature gate and documentNiko Matsakis-8/+9
They used to be covered by `optin_builtin_traits` but negative impls are now applicable to all traits, not just auto traits. This also adds docs in the unstable book for the current state of auto traits.
2020-03-18Rollup merge of #69837 - jonas-schievink:gen-discr-opt, r=tmandryMazdak Farrokhzad-7/+141
Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this, so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases
2020-03-16Rollup merge of #69867 - ↵Dylan DPC-0/+1
ayushmishra2005:doc/61137-add-long-error-code-e0628, r=Dylan-DPC Add long error explanation for E0628 Add long explanation for the E0628 error code Part of #61137 r? @GuillaumeGomez
2020-03-14Fix rebase falloutJonas Schievink-2/+2
2020-03-14Add a test for generator discriminantsJonas Schievink-0/+134
2020-03-14Use smaller discriminants for generatorsJonas Schievink-5/+5
2020-03-14Auto merge of #69716 - jonas-schievink:generator-size, r=tmandrybors-1/+103
Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words, there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis, but that seems much harder to pull off, so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as "not live" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)
2020-03-10Add long error explanation for E0628 #61137Ayush Kumar Mishra-0/+1
2020-03-09Add test for issue-64620Yuki Okushi-0/+18
2020-03-06Add test for generator sizes with resume argumentsJonas Schievink-0/+28
2020-03-05Move stray generator test into the `generator` dirJonas Schievink-0/+70
2020-03-04Move formatting to different functionJonas Schievink-1/+5
This slims down the generator MIR considerably, which makes debugging easier
2020-02-20Add regression testJonas Schievink-0/+30
2020-02-16Do not ICE when encountering `yield` inside `async` blockEsteban Küber-0/+15
2020-02-12Account for `Pin::new(_)` and `Pin::new(Box::new(_))` when `Box::pin(_)` ↵Esteban Küber-2/+2
would be applicable
2020-02-10add main function to issue-69017 testChris Simpkins-0/+2
2020-02-10add issue 69017 testChris Simpkins-0/+16
2020-02-06Ignore panic-drops-resume.rs on wasm/emscriptenJonas Schievink-0/+2
It does not have unwinding support
2020-02-04Remove obsolete testJonas Schievink-49/+0
2020-02-04Update error message with too many parametersJonas Schievink-2/+3
2020-02-04Add more tests for generator resume argumentsJonas Schievink-0/+67
2020-02-03Fix miscompilationJonas Schievink-0/+45
2020-02-02Teach dropck about resume argumentsJonas Schievink-3/+52
2020-02-02Add test for E0628 (too many generator parameters)Jonas Schievink-0/+15
2020-02-02Add tests for generator resume argumentsJonas Schievink-0/+135
2020-02-02Fix error message on type mismatch in generatorJonas Schievink-0/+41
Instead of "closure is expected to take 0 arguments" we now get the expected type mismatch error.
2020-02-02Adjust tests to type inference changesJonas Schievink-18/+49
This makes some error messages ungreat, but those seem to be preexisting bugs that also apply to closures / return position `impl Trait` in general.
2020-02-02Add a resume type parameter to `Generator`Jonas Schievink-67/+70
2020-02-02Auto merge of #68672 - jonas-schievink:dedup-witness, r=Zoxcbors-1/+1
Deduplicate types in the generator witness For the `await-call-tree` benchmark this often reduces the types inside the witness from 12 to 2.
2020-02-01Deduplicate generator interior typesJonas Schievink-1/+1
2020-01-31Auto merge of #68080 - varkor:declared-here, r=petrochenkovbors-1/+1
Address inconsistency in using "is" with "declared here" "is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout. r? @Centril
2020-01-24Normalise diagnostics with respect to "the X is declared/defined here"varkor-1/+1