Hi John,
It’s certainly true, that wrong documentation needs to be fixed. In the current example I have done that for my own benefit.
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of John Cortell
Sent: Mittwoch, 06. April 2011 20:02
To: CDT General developers list.; CDT General developers list.
Subject: Re: [cdt-dev] cdt parser change in behavior
Importance: Low
So if the behavioral change was unintentional, but innocuous, the next questions is whether to keep the new behavior or revert it. If the answer is "keep it", then the javadoc for those methods should be updated to reflect the new behavior,
as the current descriptions are misleading given the new behavior. And yes, I understand this is internal stuff, but wrong/misleading documentation is worse than no documentation, and that is true regardless of who is the target audience.
John
At 02:24 AM 4/6/2011, Schorn, Markus wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_30D36C1BA62C5F4892C482E607D5E77E0E1D69A0ALAMBBcorpadwrs_"
Hi,
The parser is not public API you should not be using it. If you need support for a specific language extension, you should make this part of CDT, configurable via ICPPParserExtensionConfiguration. See for example ICPPParserExtensionConfiguration.supportFunctionStyleAssembler().
In the parser, where a ?BacktrackException? is caught, the token stream is also restored to a previously saved state. Therefore the change does not make a difference for the parser itself.
In that sense the change was not intentional.
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Graydon Carla-RZ1029
Sent: Mittwoch, 06. April 2011 00:30
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] cdt parser change in behavior
Importance: Low
I would like to find out if a behavioral change in the consume() methods in AbstractGNUSourceCodeParser class was intentional (v. 1.128 as part of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=264666).
The javadoc comments for consume(int) and consume(int, int) imply that a token will not be consumed unless token types match. This was the behavior for Ganymede, but for Helios both methods now consume the token regardless of whether or not there is a match.
If this is intentional, then Freescale can work around it, but currently, we catch a BacktrackException in AbstractGNUSourceCodeParser.asmExpression() to handle some Freescale-specific syntax and the fact that the tokens are consumed regardless of a token
type match is breaking our custom support.
Thanks. --Carla Graydon, Freescale Semiconductor
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
