CompleteTypeBindingsSteps.INTEGRATE_ANNOTATIONS_IN_HIERARCHY violates TypeBinding's protocol by direct updation of fields in various places

[srikanth-sankaran]

• Fixes CompleteTypeBindingsSteps.INTEGRATE_ANNOTATIONS_IN_HIERARCHY violates TypeBinding's protocol by direct updation of fields in various places #4823

[srikanth-sankaran]

In this PR I have inspected and sanitized the assignments to all 8 fields of org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding that are marked with the comment // MUST NOT be modified directly, use setter !

The 3 fields of TypeVariableBinding that carry the same comment are better scrutinized by @stephan-herrmann

So this PR should be seen as work in progress and taken to completion.

I don't think we need to bend over backwards writing tests for these changes. To future proof this code against regression by a future change, I have simply opted to call out in the code that direct assignment should not be done.

I think that plenty future proofing :)

[iloveeclipse]

sanitized the assignments to all 8 fields of org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding that are marked with the comment // MUST NOT be modified directly, use setter !

Can we made the fields protected or private in 4.40? It is not API.
For now, I would also add javadoc style comments to them too saying that one should never modify them directly.

[srikanth-sankaran]

Can we made the fields protected or private in 4.40?

Thing is they should not be assigned directly by the declaring class itself, because important side effects are encoded inside the corresponding set method. (Unless the developer is absolutely sure those side effects are not desirable in some situation, that is). This intent is not capturable directly under the access protection model of the language. (although it would be step in the right direction - yes so may be we should/could)