Skip to content

[pattern-match] Make sure that when we are extracting a tuple that we fail if we have a non-instruction result. #29632

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

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Feb 4, 2020

The specific problem here is this:

sil @builtin_array_opt_index_raw_pointer_to_index_addr_no_crash : $@convention(thin) (Builtin.RawPointer, Builtin.
Word) -> Builtin.Word {
bb0(%0 : $Builtin.RawPointer, %1 : $Builtin.Word):
  %2 = index_raw_pointer %0 : $Builtin.RawPointer, %1 : $Builtin.Word
  %3 = pointer_to_address %2 : $Builtin.RawPointer to [strict] $*Builtin.Word
  %4 = load %3 : $*Builtin.Word
  return %4 : $Builtin.Word
}

before this commit, we unconditionally called getDefiningInstruction when
looking at %1. This of course returned a null value causing the compiler to
crash in a dyn_cast().

rdar://59138369

… fail if we have a non-instruction result.

The specific problem here is this:

```
sil @builtin_array_opt_index_raw_pointer_to_index_addr_no_crash : $@convention(thin) (Builtin.RawPointer, Builtin.
Word) -> Builtin.Word {
bb0(%0 : $Builtin.RawPointer, %1 : $Builtin.Word):
  %2 = index_raw_pointer %0 : $Builtin.RawPointer, %1 : $Builtin.Word
  %3 = pointer_to_address %2 : $Builtin.RawPointer to [strict] $*Builtin.Word
  %4 = load %3 : $*Builtin.Word
  return %4 : $Builtin.Word
}
```

before this commit, we unconditionally called getDefiningInstruction when
looking at %1. This of course returned a null value causing the compiler to
crash in a dyn_cast<TupleExtractInst>().

rdar://59138369
@gottesmm
Copy link
Contributor Author

gottesmm commented Feb 4, 2020

@swift-ci smoke test and merge

@swift-ci swift-ci merged commit 7e11809 into swiftlang:master Feb 4, 2020
@gottesmm gottesmm deleted the pr-0071f3d29aed40bc5467e019b4191f7ce624e042 branch February 4, 2020 18:08
Copy link
Contributor

@atrick atrick left a comment

Choose a reason for hiding this comment

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

LGTM

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.

3 participants