Bug 38065 - Handling include statements with backslashes in Outline
Summary: Handling include statements with backslashes in Outline
Status: CLOSED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 1.2   Edit
Assignee: John Camelon CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2003-05-23 15:40 EDT by Brent Nicolle CLA
Modified: 2009-01-09 17:01 EST (History)
0 users

See Also:


Attachments
Patch (3.38 KB, patch)
2003-06-04 15:40 EDT, Victor Mozgin CLA
bjorn.freeman-benson: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Nicolle CLA 2003-05-23 15:40:59 EDT
CDT 1.1 GA.  Visual Studio 6.

I imported a Visual Studio 6 project with a file containing:
#include ".\MICore\Session.h"
This shows up in the Outline as
".MICoreSession.h"  [should contain backslashes]

Selecting the item in the Outline highlights the following text in the editor:
#include ".\MICore\Session.h"
            ----------------
[should also include the first two characters]
Further experimentation showed that the number of backslashes affected the
number of missing characters highlighted in the editor.

The workaround is to change the backslashes to slashes.
Comment 1 Alain Magloire CLA 2003-05-28 10:45:05 EDT
Agreed.

No interpretation should done by the parser on the include string.  The include
string should be pass "as is" to be interpreted by the underlying filesystem
in dependent manner.

Seems a bug to me.

Reassing to John, the parser god.
Comment 2 Victor Mozgin CLA 2003-06-04 15:40:34 EDT
Created attachment 5061 [details]
Patch

   The problem is caused by the scanner: it mistreated '\' characters.
getChar() handles "'\' as the last character on the line" scenario, where '\'
and the end-of-line are correctly skipped (imitating preprocessor activity).
But it didn't backtrack properly in other cases, effectively skipping '\'
characters anywhere else in the code (outside strings). You could write 
  cl\ass C\Foo\Bar {
and it was automagically transformed to
  class CFooBar {
for the parser.
  Now getChar() does additional ungetChar() in case '\' is not the last
character on the line (and it throws ScannerException, from ungetChar()).
Comment 3 John Camelon CLA 2003-06-05 16:29:53 EDT
I have applied your patch to both HEAD and Parser_SymbolTable branches.
Comment 4 Brent Nicolle CLA 2003-06-13 11:07:46 EDT
Verified in 1.2.0.3
Closing.