diff options
| author | Dylan DPC <dylan.dpc@gmail.com> | 2020-01-06 12:00:16 +0530 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-01-06 12:00:16 +0530 |
| commit | 36920750499f5ad03cd2c35dabf09094fba7b679 (patch) | |
| tree | b031b79a5a4da555152caeb52b07fa3694bb6f7e /src/test/debuginfo/enum-thinlto.rs | |
| parent | 33640f0e03af2fb31ce380d5389d5545f24ce29a (diff) | |
| parent | 336b902f669167d09782702dffcc12513ebc8950 (diff) | |
| download | rust-36920750499f5ad03cd2c35dabf09094fba7b679.tar.gz rust-36920750499f5ad03cd2c35dabf09094fba7b679.zip | |
Rollup merge of #67800 - Aaron1011:fix/mir-generic-instance, r=oli-obk
Fix ICE involving calling `Instance.ty` during const evaluation Fixes #67639 `Instance.ty` assumes that we are in a fully monomorphic context (e.g. codegen), and can therefore use an empty `ParamEnv` when performing normalization. Howver, the MIR constant evaluator code ends up calling `Instance.ty` as a result of us attemptign to 'speculatively' const-evaluate generic functions during const propagation. As a result, we may end up with projections involving type parameters (e.g. <T as MyTrait>::Bar>) in the type we are trying to normalize. Normalization expects us to have proper predicates in the `ParamEnv` for such projections, and will ICE if we don't. This commit adds a new method `Instance.ty_env`, which takes a `ParamEnv` for use during normalization. The MIR const-evaluator code is changed to use this method, passing in the proper `ParamEnv` for the context at hand.
Diffstat (limited to 'src/test/debuginfo/enum-thinlto.rs')
0 files changed, 0 insertions, 0 deletions
