diff options
| author | 许杰友 Jieyou Xu (Joe) <39484203+jieyouxu@users.noreply.github.com> | 2024-04-15 16:56:15 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-04-15 16:56:15 +0100 |
| commit | 699612fb8a2b78fd650ee61ed231ec6fed619527 (patch) | |
| tree | 55ff2262199dcf5ac7412f4d68f5ba95144d6afb /compiler/rustc_codegen_llvm/src | |
| parent | 4d2a8e3692d2ddfa932c559b1c916d6780b790e1 (diff) | |
| parent | 24653a56640305a64d31da8f87c4575112ff7184 (diff) | |
| download | rust-699612fb8a2b78fd650ee61ed231ec6fed619527.tar.gz rust-699612fb8a2b78fd650ee61ed231ec6fed619527.zip | |
Rollup merge of #123864 - oli-obk:define_opaque_types3, r=compiler-errors
Remove a HACK by instead inferring opaque types during expected/formal type checking I was wondering why I couldn't come up with a test that hits the code path of the argument check checking the types we inferred from the return type... Turns out we reject those attempts early during fudging. I have absolutely no information for you as to what kind of type inference changes this may incur, but I think we should just land this out of two reasons: * had I found the other place to use opaque type inference on before I added the hack, we'd be using that today and this PR would never have happened * if it is possible to hit this path, it requires some god awful recursive RPIT logic that I doubt anyone would have written without actively trying to write obscure code r? ``@ghost``
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions
