diff options
| author | Niko Matsakis <niko@alum.mit.edu> | 2015-06-09 17:02:18 -0400 |
|---|---|---|
| committer | Niko Matsakis <niko@alum.mit.edu> | 2015-06-15 17:31:26 -0400 |
| commit | ff89fcf83b41c2759d69c01d5e41b9043f5acff8 (patch) | |
| tree | 8a5bce8dfc3f0afebc34f552bc2a8e138be0897d /src/rustllvm/RustWrapper.cpp | |
| parent | 0d82fb55dbb9b28798ea7c2004fa91fe3ae23b86 (diff) | |
| download | rust-ff89fcf83b41c2759d69c01d5e41b9043f5acff8.tar.gz rust-ff89fcf83b41c2759d69c01d5e41b9043f5acff8.zip | |
Add a (somewhat hacky) cache to the tcx that tracks "global" trait refs
that are known to have been satisfied *somewhere*. This means that if one fn finds that `SomeType: Foo`, then every other fn can just consider that to hold. Unfortunately, there are some complications: 1. If `SomeType: Foo` includes dependent conditions, those conditions may trigger an error. This error will be repored in the first fn where `SomeType: Foo` is evaluated, but not in the other fns, which can lead to uneven error reporting (which is sometimes confusing). 2. This kind of caching can be unsound in the presence of unsatisfiable where clauses. For example, suppose that the first fn has a where-clause like `i32: Bar<u32>`, which in fact does not hold. This will "fool" trait resolution into thinking that `i32: Bar<u32>` holds. This is ok currently, because it means that the first fn can never be calle (since its where clauses cannot be satisfied), but if the first fn's successful resolution is cached, it can allow other fns to compile that should not. This problem is fixed in the next commit.
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
