Summary: | [Scanner] Unable to macro expand operator ## with "0xxyz" argument | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] CDT | Reporter: | Mas Yokota <myokota> | ||||
Component: | cdt-parser | Assignee: | John Camelon <john.camelon> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | aniefer | ||||
Version: | 2.0 | ||||||
Target Milestone: | 2.0.1 | ||||||
Hardware: | PC | ||||||
OS: | Windows 2000 | ||||||
Whiteboard: | |||||||
Bug Depends on: | 61972 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Mas Yokota
2004-05-17 18:03:47 EDT
Created attachment 10756 [details]
test case
The resultant outline view is as follows: A1Xxyz : int B1X1X1Xxyz : int CC0Xxyz : int Dxyz : int E0x0x0xxyz : int As you can see, C0Xxyz is missing and D0xxyz is coming out as Dxyz. Update: The problem is that when we lookahead for macro pasting, we are expecting a valid token. 0xxyz is not a valid identifier format, or a valid hexidecimal integer format, and thus it causes an error. Mr. Niefer, as the originator of this strategy, do you have any suggestions as to how we can get past this? PR was targeted to the 2.0 release but not resolved, moving target to 2.1 This is a 2.0.1 candidate. This defect is fixed in HEAD w/Scanner2 implementation. It shall be marked as resolved once it has been fixed in 2.0.1 as well. The merge from HEAD to 2_0 branch is complete. JUnits validating these fixes have been committed to both branches. Marking as RESOLVED - FIXED. The next available 2.0.1 build shall contain these fixes along with Parser performance/scalability improvements. |