Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[compiler] Teach type inference that GotoIfNot can throw #48583

Merged
merged 1 commit into from
Feb 7, 2023

Conversation

staticfloat
Copy link
Member

Previously, the effects system would ignore certain cases where GotoIfNot nodes would be capable of throwing; this resulted in simple examples such as the following being marked as nothrow:

julia> foo(x) = x > 0 ? x : 0
       Base.infer_effects(foo, (Missing,))
(+c,+e,+n,+t,+s,+m,+i)

With this change, we correctly notice when a GotoIfNot node is given a non-Bool condition, annotate the basic block as possibly throwing, and further end type inference if the condition is provably non-Bool.

Previously, the effects system would ignore certain cases where
`GotoIfNot` nodes would be capable of throwing; this resulted in simple
examples such as the following being marked as `nothrow`:

```
julia> foo(x) = x > 0 ? x : 0
       Base.infer_effects(foo, (Missing,))
(+c,+e,+n,+t,+s,+m,+i)
```

With this change, we correctly notice when a `GotoIfNot` node is given a
non-`Bool` condition, annotate the basic block as possibly throwing, and
further end type inference if the condition is provably non-`Bool`.
@vchuravy vchuravy added the backport 1.9 Change should be backported to release-1.9 label Feb 7, 2023
@vchuravy
Copy link
Member

vchuravy commented Feb 7, 2023

Labeled as backport under the assumption that this is an effect bugfix for 1.9 as well.

@Keno Keno merged commit 68ada71 into master Feb 7, 2023
@Keno Keno deleted the sf/gotoifnot_throw branch February 7, 2023 23:34
Copy link
Member

@aviatesk aviatesk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@KristofferC KristofferC mentioned this pull request Feb 20, 2023
50 tasks
KristofferC pushed a commit that referenced this pull request Feb 20, 2023
Previously, the effects system would ignore certain cases where
`GotoIfNot` nodes would be capable of throwing; this resulted in simple
examples such as the following being marked as `nothrow`:

```
julia> foo(x) = x > 0 ? x : 0
       Base.infer_effects(foo, (Missing,))
(+c,+e,+n,+t,+s,+m,+i)
```

With this change, we correctly notice when a `GotoIfNot` node is given a
non-`Bool` condition, annotate the basic block as possibly throwing, and
further end type inference if the condition is provably non-`Bool`.

(cherry picked from commit 68ada71)
@KristofferC
Copy link
Member

This causes a regression on 1.9 when backported in that any(Returns(0), [false]) no longer throws, so removing from backport label.

@oscardssmith
Copy link
Member

does this also affect 1.10?

@KristofferC
Copy link
Member

It's in CI so 1.10 seems to be fine. I noticed on 1.9 due to test failure:

julia/test/reduce.jl

Lines 481 to 482 in 6523b0c

@test_throws TypeError any(Returns(0), [false])
@test_throws TypeError all(Returns(0), [false])

aviatesk pushed a commit that referenced this pull request Feb 22, 2023
Previously, the effects system would ignore certain cases where
`GotoIfNot` nodes would be capable of throwing; this resulted in simple
examples such as the following being marked as `nothrow`:

```
julia> foo(x) = x > 0 ? x : 0
       Base.infer_effects(foo, (Missing,))
(+c,+e,+n,+t,+s,+m,+i)
```

With this change, we correctly notice when a `GotoIfNot` node is given a
non-`Bool` condition, annotate the basic block as possibly throwing, and
further end type inference if the condition is provably non-`Bool`.
@KristofferC KristofferC removed the backport 1.9 Change should be backported to release-1.9 label Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants