What happens: In MonoLints.java, ALL_NAMES is computed from MonoLints.LINTS (which contains only PkByXsl lints, LtAsciiOnly, and LtReservedName) plus LtUnlintNonExistingDefect. The LtIncorrectUnlint lint itself is not part of LINTS — it is added in the MonoLints constructor after ALL_NAMES is already frozen. As a result, "incorrect-unlint" is never added to ALL_NAMES. When LtIncorrectUnlint validates a +unlint incorrect-unlint meta against ALL_NAMES, it does not find the name and emits: "Suppressing 'incorrect-unlint' does not make sense, because there is no lint with that name" — even though incorrect-unlint is a real, registered lint. By contrast, "unlint-non-existing-defect" is explicitly added to ALL_NAMES, so +unlint unlint-non-existing-defect is accepted. The two sibling lints are treated asymmetrically.
What should happen: "incorrect-unlint" should be present in ALL_NAMES so that LtIncorrectUnlint recognises it as a valid lint name and does not raise a false-positive error for +unlint incorrect-unlint.
What happens: In
MonoLints.java,ALL_NAMESis computed fromMonoLints.LINTS(which contains onlyPkByXsllints,LtAsciiOnly, andLtReservedName) plusLtUnlintNonExistingDefect. TheLtIncorrectUnlintlint itself is not part ofLINTS— it is added in theMonoLintsconstructor afterALL_NAMESis already frozen. As a result,"incorrect-unlint"is never added toALL_NAMES. WhenLtIncorrectUnlintvalidates a+unlint incorrect-unlintmeta againstALL_NAMES, it does not find the name and emits: "Suppressing 'incorrect-unlint' does not make sense, because there is no lint with that name" — even thoughincorrect-unlintis a real, registered lint. By contrast,"unlint-non-existing-defect"is explicitly added toALL_NAMES, so+unlint unlint-non-existing-defectis accepted. The two sibling lints are treated asymmetrically.What should happen:
"incorrect-unlint"should be present inALL_NAMESso thatLtIncorrectUnlintrecognises it as a valid lint name and does not raise a false-positive error for+unlint incorrect-unlint.