-
Notifications
You must be signed in to change notification settings - Fork 62
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
Allow use of plain field names with jvm_field_is
#902
Labels
subsystem: crucible-jvm
Issues related to Java verification with crucible-jvm
Comments
brianhuffman
added
the
subsystem: crucible-jvm
Issues related to Java verification with crucible-jvm
label
Nov 14, 2020
brianhuffman
pushed a commit
that referenced
this issue
Nov 18, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
brianhuffman
pushed a commit
that referenced
this issue
Nov 18, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
brianhuffman
pushed a commit
that referenced
this issue
Nov 18, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
brianhuffman
pushed a commit
that referenced
this issue
Nov 18, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
brianhuffman
pushed a commit
that referenced
this issue
Nov 18, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
brianhuffman
pushed a commit
that referenced
this issue
Nov 18, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
brianhuffman
pushed a commit
that referenced
this issue
Nov 19, 2020
It now performs field resolution on the base field name to determine the complete fieldId including class name and type. This implements part of the feature requested in #902. However, as it stands the feature is not backward-compatible, as *only* unqualified names currently work. The field resolution procedure needs to be updated to allow optional qualified names.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently when writing jvm specs,
jvm_field_is
declarations must be used with a fully-qualified field name that includes the class name. Here's an example setup block fromecdsa-crucible.saw
:In order to determine the right fully-qualified name for field
h
, the user has to basically perform a full field resolution procedure: No fieldh
is declared in classP384ECC64
, so check the superclassNIST64
. There's no fieldh
inNIST64
either, so check its superclassECCProvider
. Finally, we find thatECCProvider
does declare a fieldh
, so that's the qualified name we use.Instead of making the user do this, saw should do it automatically. The user should be able to write
jvm_field_is this "h" ph
. Thensaw
should look up the class of thethis
reference, and resolve the field nameh
by checking the superclasses in order until a match is found.Even so, we probably want to continue to allow users to optionally specify fully-qualified field names that include a classname. This is occasionally necessary in the case where a subclass declares a field that shadows a similarly-named field in a superclass; in such cases the unqualified name would always default to the field of the subclass.
The text was updated successfully, but these errors were encountered: