[cfe-dev] Distinguishing system headers from user headers using libclang

[Siedlarek, Mikołaj]

On Thu, Apr 11, 2013 at 7:22 PM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote:
> On Apr 5, 2013, at 4:20 AM, "Siedlarek, Mikołaj" <m.siedlarek at nctz.net>
> wrote:
>
> On Fri, Apr 5, 2013 at 12:37 PM, Siedlarek, Mikołaj
> <m.siedlarek at nctz.net> wrote:
>
> On Fri, Apr 5, 2013 at 12:22 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com>
> wrote:
>
>
> On Apr 2, 2013, at 1:33 AM, Mikołaj Siedlarek <m.siedlarek at nctz.net> wrote:
>
> Hi,
>
> I'm writing a simple code dependency analysis tool using libclang and I'm
> missing some way of distinguishing system headers from user headers. I see
> clang::DirectoryLookup::getDirCharacteristic() provides such interface, but
> is there any way I could obtain this information using just libclang? My
> tool is rather simple and I'd like to keep it that way - libclang seems to
> be sufficient for the rest of my needs.
>
>
> There is no way currently, but it should relatively easy, are you interested
> in providing such a patch ?
> The clang function you may need to look into using is
> "SourceManager::isInSystemHeader(SourceLocation Loc)"
> The libclang function would accept a CXTranslationUnit and a
> CXSourceLocation.
>
>
>
> How about this? That's the best and most elastic approach I could think of.
>
>
> There was unnecessary CINDEX_LINKAGE in the first version of my patch.
> Here's corrected one.
>
>
> +  /**
> +   * \brief System code which is implicitly 'extern "C"' in C++ mode
> +   */
> +  CXCharacteristicKind_ExternCSystem
>
> This is very "legacy-hacky-compiler-specific"; I can't think of a reason
> that a libclang client would need to know this.
>
> I suggest just adding a
> int clang_SourceLocation_isInSystemHeader(CXSourceLocation location)
> function.

I agree ExternCSystem may not be useful - I added it to mimic
underlaying library interface. Nevertheless, I don't think boolean
isInSystemHeader is enough. For example - in my program I need to know
whether given source location is in user code. !isInSystemHeader
wouldn't be enough, because there are also invalid locations like
built-in compiler declarations or anything really that has no
corresponding location in the source.

-- 
Mikołaj Siedlarek
m.siedlarek at nctz.net