typetools / typetools/checker-framework

More focused warning suppression for uninitialized fields in Nullness Checker

Open
#121 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
1.1k
Forks
440
Avg merge
1d 12h
Merged PRs (30d)
134

Description

When code ensures that a field is initialized, in a way that is beyond the 
capabilities of the Nullness type system, it is possible to suppress the 
warning with @SuppressWarnings("nullness:fields.uninitialized") on the 
constructor.  However, this suppresses initialization warnings about all 
uninitialized fields, and a programmer might only want to suppress warnings 
about specific fields that are initialized in some unusual way.

This is a feature request for a new @SuppressWarnings key.  A programmer should 
be able to write

@SuppressWarnings("nullness:fields.uninitialized:fieldname1,fieldname2")

to suppress initialization warnings related to the two named fields.  A 
programmer would add this to specific constructors, where the programmer knows 
by manual reasoning that the given fields are initialized.

As an additional feature, it would be nice to permit writing

@SuppressWarnings("nullness:fields.uninitialized")

on a field declaration to suppress initialization warnings for all constructors.

Original issue reported on code.google.com by michael.ernst@gmail.com on 23 Dec 2011 at 9:31

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how the Nullness Checker processes @SuppressWarnings("nullness:fields.uninitialized") and reports uninitialized-field warnings. Compare constructor-level suppression with the requested field-specific names and field-declaration behavior; done means both forms suppress only the intended diagnostics without hiding unrelated field warnings.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
compilers, devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.