Community
Participate
Working Groups
Follow-up of bug 102780 comment 23. While implementing the new comment formatter for 3.4 version, a new flag has been added to include comments while formatting a compilation unit. It means that currently this flag only works either when K_COMPILATION_UNIT kind is used or when K_UNKNOWN flag is used and the snippet is a compilation unit... As there's no design reason to have this limitation, next version should fix it and make this flag meaningful for all kinds of snippet. Note that for comment kinds, this flag has and still will have no effect as it's redundant...
Unfortunately, I missed this one for 3.5 => reset the target
Frédéric, this would be a good candidate in your current work on the formatter.
Created attachment 159206 [details] Proposed patch This patch makes the flag F_INCLUDE_COMMENTS also working for K_EXPRESSION, K_CLASS_BODY_DECLARATIONS and K_STATEMENTS. Note that it also removes the internal possibility to deactivate the 'new' comment formatter (as it should have been done in 3.5...). Hence, there won't be any possibility to retrieve the "old" comment formatter behavior...
As long as we get a proper comment formatting, this is fine. Once the last dependency is removed, we should remove the corresponding old code.
Created attachment 159275 [details] Proposed patch + Marking obsolete code deprecated Same implementation in this patch than the previous but I just deprecated classes used by the "old" comment formatter and warned that this code will be removed for 3.6M6. Olivier, if you agree with this more "aggressive" patch, then I'll also post a warning on the jdt-core-dev mailing list...
comment #5 should read: "...and warned that this code will be removed for 3.6."
(In reply to comment #5) > Olivier, if you agree with this more "aggressive" patch, then I'll also post a > warning on the jdt-core-dev mailing list... Looking at use scan results, we don't have any references to this internal code. Now to be safe, tagging as deprecated might be good enough for 3.6. Daniel ?
>Looking at use scan results, we don't have any references to this internal >code. Now to be safe, tagging as deprecated might be good enough for 3.6. >Daniel ? Assuming you checked the scans, simply remove the internal code (no deprecation) right away. Products working against 3.6 will immediately see it and can react. References from products based on 3.5 or 3.4 would surface in the API scans. Do we have to adjust some API Javadoc?
(In reply to comment #8) > >Looking at use scan results, we don't have any references to this internal > >code. Now to be safe, tagging as deprecated might be good enough for 3.6. > >Daniel ? > Assuming you checked the scans, simply remove the internal code (no > deprecation) right away. Products working against 3.6 will immediately see it > and can react. References from products based on 3.5 or 3.4 would surface in > the API scans. > > Do we have to adjust some API Javadoc? I'll check that and repost a patch with obsolete code removed...
Created attachment 159416 [details] New proposed patch This patch removes all the obsolete internal code. It also refresh the CodeFormatter javadoc comments...
(In reply to comment #10) > Created an attachment (id=159416) [details] > New proposed patch > Released for 3.6M6 in HEAD stream.
Verified for 3.6M6 using build I20100305-1011
