Revamp kinds for bounds expressions #50
Milestone
Comments
dtarditi
added a commit
to dtarditi/checkedc-clang
that referenced
this issue
Sep 14, 2016
Instead of having separate kind enumerations for different bounds expression classes, have just one kind enumeration for all bounds expression classes. This makes it easier to write predicates that check for a specific kind of bounds expression, without having to do a dynamic type test and cast to the specific bounds expression type. This addresses Github issue checkedc#50. The downside of the unified kind enumeration is that a developer can use a kind that is invalid for a specific bounds expression class. Add code to validate the kind information. Add predicates for testing for specific kinds of bounds expressions and clean up code for type checking bounds expressions by using the predicates. This also adds a kind for the `: ptr` interop bounds annotation to the kind enumeration for bounds expressions. Testing: - Passes existing clang and Checked C tests.
dtarditi
added a commit
that referenced
this issue
Sep 15, 2016
Instead of having separate kind enumerations for different bounds expression classes, have just one kind enumeration for all bounds expression classes. This makes it easier to write predicates that check for a specific kind of bounds expression, without having to do a dynamic type test and cast to the specific bounds expression type. This addresses Github issue #50. The downside of the unified kind enumeration is that a developer can use a kind that is invalid for a specific bounds expression class. Add code to validate the kind information. Add predicates for testing for specific kinds of bounds expressions and clean up code for type checking bounds expressions by using the predicates. This also adds a kind for the `: ptr` interop bounds annotation to the kind enumeration for bounds expressions. Testing: - Passes existing clang and Checked C tests.
|
This work is complete. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be good to have one kind field on bounds expressions instead of specialized kinds per type of bounds expressions. This would make it easier to write code that traverses bounds expressions. Currently, we have to test the type of a bounds expression and then look at the kind field.
The text was updated successfully, but these errors were encountered: