cherry-pick of more bugfixes from fixing #265 #19388
Conversation
|
Are there tests for any of these? |
|
Also it would be preferable if we could use the term "backport" to mean exactly one thing - if the target branch is still master and the PR they come from hasn't been merged yet, then this is different from what we use the "backport pending" labels to track. Better to call this cherry pick or something distinct so it doesn't look related to release tracking. |
vtjnash
force-pushed
the
jn/backports265.5
branch
from
969d433
to
5447350
Compare
and make the code a bit more flexible to be able to handle these oddball cases more easily in the future
otherwise, it sometimes has been pointing at free'd memory and we have just been hoping nothing tries to look at it
sorry, this was badly munged
vtjnash
changed the title
|
bump |
only the variable changes need to be propagated on each step to the exception frame (as the whole frame was already synced when handling `Expr(:enter)`) this eliminates an unnecessary exponential pass for handling exception frames along the way, this replaces `(e::Slot).id` with a manually expanded version `slot_id(e)`. Since Slot is a abstract variable, Inference has no way to directly track that the set of subtypes won't change, so it had to be pessimistic and assume that the value was Any. Adding a function barrier removes that difficulty. (cherry-picked from d25e94b, PR #19388)
|
This doesn't cherry-pick cleanly on release-0.5. If these are fixing anything important, please open a PR against tk/backports-0.5.1. |
|
Since #265 wasn't fixed on 0.5, I would imagine this is not relevant? |
|
this is a confusingly named pr, it's miscellaneous bugfixes that jameson did while working on 265, but split out to a separate branch here |
|
Right. This is split out because it wasn't #265-related, even though they were developed during that PR |
this is a backport of additional fixes I had made to avoid segfaults on my #265-fix branch (#17057)