It seems odd that there is an initializedFields in NullnessNoInitStore
|
* Initialized fields and their values. |
A field with the same name, but a different type is in the InitializationStore
|
protected final Set<VariableElement> initializedFields; |
When removing the field from NullnessNoInitStore and its uses, there are some errors here:
|
// TODO: reinstate. This shows desired features, for initialization in |
(That comment should be cleaned up.)
The problem seems to be that the non-pure method invocation loses which fields were already initialized.
Investigate this to see whether this would reduce memory use and reduce redundant computations.
It also seem odd that the field isn't used e.g. in LUB:
|
NullnessNoInitStore lub = super.leastUpperBound(other); |
It seems odd that there is an
initializedFieldsinNullnessNoInitStorechecker-framework/checker/src/main/java/org/checkerframework/checker/nullness/NullnessNoInitStore.java
Line 30 in cb4ba31
A field with the same name, but a different type is in the
InitializationStorechecker-framework/checker/src/main/java/org/checkerframework/checker/initialization/InitializationStore.java
Line 28 in cb4ba31
When removing the field from
NullnessNoInitStoreand its uses, there are some errors here:checker-framework/checker/tests/initialization/RawTypesInit.java
Line 240 in cb4ba31
(That comment should be cleaned up.)
The problem seems to be that the non-pure method invocation loses which fields were already initialized.
Investigate this to see whether this would reduce memory use and reduce redundant computations.
It also seem odd that the field isn't used e.g. in LUB:
checker-framework/checker/src/main/java/org/checkerframework/checker/nullness/NullnessNoInitStore.java
Line 118 in cb4ba31