-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b64
-
generic
-
generic
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8085502 | emb-9 | Srikanth Adayapalam | P4 | Resolved | Fixed | team |
While working on JDK-8062373, it has been observed that it would be better to
refactor the method Attr.check to receive a parameter enumeration 'CheckMode'
of the form
enum CheckMode {
NORMAL,
NO_TREE_UPDATE,
NO_INFERENCE_HOOK
}
so clients can control better:
(1) Whether they want Attr.check to install/manage post-inference hooks on their behalf
or not. Certain clients may prefer Attr.check to not install post-inference-hooks as illustrated
by the work on <> with anonymous classes.
(2) Whether they want updates in the tree's type or not. Presently when a client wants the
tree to not be updated, the code base relies on a hack of passing a special AST fragment
called a noCheckTree.
While the original observation was to refactor Attr.check, more work will be involved in getting
rid of the noCheckTree hack: While noCheckTree discriminant is consulted only in Attr.check,
it gets passed to other methods notably Attr.checkId and gets tunnelled into Attr.check via a
host of methods all of which will likely have to also be refactored. Some of these methods are:
Attr.check, Attr.checkId, Attr.checkMethodIdInternal, Attr.checkSigPolyMethodId, Attr.checkMethodId,
Attr.checkIdInternal etc.
We may also have to tweak the enumeration a bit - There is no way to combine NO_TREE_UPDATE
and NO_INFERENCE_HOOK - though there is no use case for this ATM.
refactor the method Attr.check to receive a parameter enumeration 'CheckMode'
of the form
enum CheckMode {
NORMAL,
NO_TREE_UPDATE,
NO_INFERENCE_HOOK
}
so clients can control better:
(1) Whether they want Attr.check to install/manage post-inference hooks on their behalf
or not. Certain clients may prefer Attr.check to not install post-inference-hooks as illustrated
by the work on <> with anonymous classes.
(2) Whether they want updates in the tree's type or not. Presently when a client wants the
tree to not be updated, the code base relies on a hack of passing a special AST fragment
called a noCheckTree.
While the original observation was to refactor Attr.check, more work will be involved in getting
rid of the noCheckTree hack: While noCheckTree discriminant is consulted only in Attr.check,
it gets passed to other methods notably Attr.checkId and gets tunnelled into Attr.check via a
host of methods all of which will likely have to also be refactored. Some of these methods are:
Attr.check, Attr.checkId, Attr.checkMethodIdInternal, Attr.checkSigPolyMethodId, Attr.checkMethodId,
Attr.checkIdInternal etc.
We may also have to tweak the enumeration a bit - There is no way to combine NO_TREE_UPDATE
and NO_INFERENCE_HOOK - though there is no use case for this ATM.
- backported by
-
JDK-8085502 Refactor Attr.check* methods to receive/handle a CheckMode enumeration
-
- Resolved
-