• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Indexer and preprocessor symbols
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Indexer and preprocessor symbols


  • Subject: Re: Indexer and preprocessor symbols
  • From: Chris Espinosa <email@hidden>
  • Date: Sun, 24 Jul 2005 13:26:37 -0700

On Jul 24, 2005, at 11:37 AM, Andreas Grosam wrote:

The indexer does not determine the state of macros correctly when they have been defined in the build settings panels ( in Other C/C++ Flags respectively Preprocessor Macros).
As a result, it also does not determine and locate derived macros correctly.


Example:

#if defined (NDEBUG)
#define XXX xxx
#else
#define XXX yyy
#endif

The indexer does not determine the state of NDEBUG, if it is defined in the build settings (as opposed to when it is defined in a file), thus, also does not determine the definition of the derioved macro XXX correctly.
That is <command>-double-click, does not route me to the line where XXX is/will be actually defined.


There is also no documentation, which build settings will be used when the indexer is doing its work. Strictly, for each translation unit, there might be different definitions!
In my case, i urgently need to locate derived macros correctly, which are different in two targets, and also different in Release/Debug versions.
That means, building *one* index for the whole project is worthless - since there are different definitions, which i need to figure out.

That's correct. We plan to index more information about symbols (of all kinds, not just macros) in the future, especially target and configuration information.

Is this a known bug in XCode 2.1, or should I file one?

It is one of the many well-known limitations of the indexer. There are some clear things we can do to help the situation without making the index slow(er) and huge(r), but we need to balance completeness against efficiency, as getting the Right Answer (that is, the value of everything as the compiler will see it in every situation) would almost require us to run all sources through the preprocessor in every target/configuration combination at indexing time.


The problem is not perfectly solveable: there may be macros defined on conditional circumstances, or pasted together with the ## operator, or based on other criteria unavailable to Xcode. Compiler-predefined macros as well will not be indexed. Functions defined by conditionally-defined macros also won't necessarily be indexed properly. The nature of the C preprocessor makes this harder than it ought to be, though as I said above, we intend to do better than we're doing now.

If you wish to write this up, you can refer to (and it will probably be made a duplicate of) <rdar://problem/3431454>,

Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Indexer and preprocessor symbols (From: Andreas Grosam <email@hidden>)

  • Prev by Date: Re: Developer Transition System
  • Next by Date: building with gcc 4.0
  • Previous by thread: Indexer and preprocessor symbols
  • Next by thread: building with gcc 4.0
  • Index(es):
    • Date
    • Thread