Range overflow for irritants in CompilerOptions

[stephan]

The long constants encoding irritants in class CompilerOptions are used for making certain classes of problems configurable (error,warning,ignore). These constants use individual bits to support storing a set of irritants within one long value. While merging Eclipse 3.4 with the OTDT we ran out of bits.

Currently, I work around this by

• discarding our previous irritants effectless_fieldaccess, unused_parammap and incomplete_build
• sacrifice JDT irritant assertIdentifier

The above problems are now invariably reported as fatal errors.

I should discuss a long-term strategy with the jdt core team. Also the JML4 people might soon run into this.

Also note, that the constants in org.eclipse.jdt.core.CompletionProposal just about hit the ceiling: 31 of 32 bits in an int are used.

[stephan]

Test org.eclipse.jdt.core.tests.compiler.parser.ComplianceDiagnoseTest has been adjusted for changed behavior regarding assert as identifier (r18600).

This should be reverted, once this issue is fixed (if it can be).

[stephan]

The affected compiler options are additionally disabled in the preference page (see r18670).

[stephan]

Solved in r18817 and r18820 by a different encoding:

• OT/J-irritants now use two bits: a constant OTJFlag (bit64L) to switch between sets of irritants and the individual bit

(not enabling old irritants, which are not considered very useful).

[stephan]

Based on a hint by Pilippe Mulet, r18958 adapts analysis of suppressed warnings to the new encoding. See also B.1.1-otjld-sh-67 and B.1.1-otjld-sh-68.

[stephan]

r18960 and r18961 fix regressions introduced by r18958.

[stephan]

r18963 adds special treatment to the suppress "all" irritant: in order to safely apply to irritants of both sets (Java-OT/J) it must first be stored in both sets.