Bug 340677 - inconsequent bindings in preprocessor names
Summary: inconsequent bindings in preprocessor names
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-indexer (show other bugs)
Version: 8.0   Edit
Hardware: PC Linux
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-22 12:05 EDT by Lukas Felber CLA
Modified: 2020-09-04 15:18 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Felber CLA 2011-03-22 12:05:32 EDT 
Build Identifier: M20100909-0800

considering the preprocessor name (which was not defined) following either #ifdef or #undef, the returned binding is in the first case an UndefinedMacro instance and in the second case null.
Is there a reason for this? for me it would make more sence to have a similar behavior here (either both null or both UndefinedMacro).

Reproducible: Always

Steps to Reproduce:
1. create a source file containing:
#ifdef A //binding of a is UndefinedBinding, name is of type ASTMacroReferenceName
#endif
#undef B //binding is null, name is of type ASTPreprocessorName