Community
Participate
Working Groups
RC1: Auto-generated modules such as AbstractXXXProposalProvider do not have on @Override annotation on overridden methods.
That is true, but we suppress all warnings for those files, so it shouldn't be an issue. Does it cause you any trouble?
Prior to M7 there were so many warnings that project-specific compiler settings were essential. M7 gave such a major improvement that I could restore settings to the same as for other MDT/OCL pligins; except that NLS must still be switched off. Some @suppressWarnings(NLS) would be good. When I regenerate editors, I have to manually add the @Overrides, mostly to the RunTimeModules. It is the in the grammars that you switched off all warnings. Not a major problem; just a nuisance; hence the minor severity on the report. Perhaps an @suppressWarnings(Override) on the relevant classes would do, unless the generation template is almost direct copy in which case fix the copy source.
We don't want to suppress warnings in user managed code (e.g. <MyLanguage>RuntimeModule). The manually adding of @Overrides was only needed once, wasn't it? Regarding the NLS warnings. I checked with the default compiler settings and couldn't find NLS warnings in the generated code. If I missed them, could you please open a new bugzilla and provide some information about which generated classes should suppress these warnings? thanks.
Having now regenerated my editors a few times at RC1, I've found that most of the @Override issues were indeed fixed. Typically I now have 18 rather than 120 overrides to restore in 3 files. The residual ones seem to be solely in AbstractXXXProposalProvider where a derived editor overrides an inherited editor's proposals.
See comment 4
Fixed in HEAD.
Closing bug which were set to RESOLVED before Eclipse Neon.0.