Revision f3d17d3d8e6df78e7b872c6f43da186148892406 authored by Keno Fischer on 22 April 2019, 00:52:27 UTC, committed by Keno Fischer on 26 April 2019, 22:01:56 UTC
After fixing #30118, the behavior of #31649 changed. Instead of crashing immediately upon attempting to print `spvec`, the first time would fail with the correct ambiguity. However, any subsequent attempts to print the same value would yet again result in a crash. Upon investigation, the series of events leading to this crash are as follows: 1. Showing the first error message attempts to put `convert(::Type{Any}, ::Nothing)` into the cache (matching the previous `convert(::Type{Any}, x::Any)` method). 2. jl_compilation_sig widens this to `convert(::DataType, x::Any)`. No guard signatures are allocated, because `ml_matches` does not return `convert(::Any, ::sparse_t)` because it is uncallable due to the ambiguity. 3. Upon the next call, we find `convert(::DataType, x::Any)` in the cache and use it. The subsequent successful return conflicts with type inference's result that this call will not return (i.e. is inferred to Union{}). To fix this change the `ml_matches` call in step 2 to include ambiguous matches, thus allocating guard entries for these signatures and preventing the cache match. That works for this issue, but I should note that I have seen additional crashes along similar lines while working on this fix, so there may be additional issues in the vicinity. Fixes #31649
1 parent a030b0a
VERSION
1.3.0-DEV
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...