Skip to content
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

Separate Initialization Checker #444

Merged
merged 142 commits into from
Sep 25, 2023
Merged

Conversation

flo2702
Copy link
Collaborator

@flo2702 flo2702 commented Mar 23, 2023

This branch rewrites the Initialization Checker such that checking of the initialization hierarchy and the target hierarchy is done in two separate checkers instead of at once. The Javadoc to the InitializationChecker class explains how this can be implemented for any given target type system.

For every type system that uses the Initialization Checker (only nullness so far), initialization checking can now be deactivated via the -AassumeInitialized command-line option or via @SuppressWarnings("initialization") annotations.

Also fixes #297.

Merge together with eisop/checker-framework.demos#4.

…trized with an invariant, but considers every field to be an invariant annotation
Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Thanks for all your further refinement!
I've pushed a few changes directly, please review them - in particular the changelog.
A few more comments about the documentation, but I haven't gone through everything yet.

Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Great work! I really like all these improvements!
I pushed a few more changes myself and asked a few more questions.

@@ -2625,7 +2642,7 @@ public boolean shouldSkipUses(@FullyQualifiedName String typeName) {
* @param tree class to potentially skip
* @return true if checker should not test {@code tree}
*/
public final boolean shouldSkipDefs(ClassTree tree) {
public boolean shouldSkipDefs(ClassTree tree) {
Copy link
Member

Choose a reason for hiding this comment

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

Instead of making these two methods non-final, how about adding handling of parentChecker to these methods?
The logic in NullnessNoInitSubchecker.java makes sense for all checkers with a parent, right?

Copy link
Member

Choose a reason for hiding this comment

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

Will be addressed by #572

Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Thanks for the final touches. I'll merge this now. Let's try it in practice and see what the feedback is.

@wmdietl wmdietl merged commit 280d513 into eisop:master Sep 25, 2023
@@ -2655,7 +2672,7 @@ public final boolean shouldSkipDefs(ClassTree tree) {
* @param meth method to potentially skip
* @return true if checker should not test {@code meth}
*/
public final boolean shouldSkipDefs(ClassTree cls, MethodTree meth) {
public boolean shouldSkipDefs(ClassTree cls, MethodTree meth) {
Copy link
Member

Choose a reason for hiding this comment

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

Undo with #572

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.

Nullness Checker: unsoundness with unboxing UnknownInitialization types
2 participants