[cfe-dev] Tooling vs -fdelayed-template-parsing WAS: Clang-cl.exe and the VC++ preprocessor

Reid Kleckner rnk at google.com
Mon Aug 4 12:07:57 PDT 2014

On Mon, Aug 4, 2014 at 10:40 AM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> On Mon, Aug 4, 2014 at 7:34 PM, Reid Kleckner <rnk at google.com> wrote:
>> On Mon, Aug 4, 2014 at 10:26 AM, Kim Gräsman <kim.grasman at gmail.com>
>> wrote:
>>> We just (a few minutes ago, while experimenting with this) found a case
>>> where late-parsing a template whose body contains undefined symbols would
>>> generate an incomplete AST, e.g.
>>> template<class T>
>>> void foo(const T& t) {
>>>   UndefinedSymbol::bar(t);  // colon-colon
>>> }
>>> $ clang-check.exe -ast-dump incomplete.cpp --
>>> -fno-delayed-template-parsing
>>> TranslationUnitDecl 0xebe7e0 <<invalid sloc>> <invalid sloc>
>>> [...]
>>> This runs without error [...]
>>> I don't know if this is a general bug in the parser, but it'd be nice to
>>> always get a diagnostic here.
>> This is an -fms-compatibility hack, which is separate from delayed
>> template parsing.  I'm surprised we don't have a -Wmicrosoft warning here,
>> though.
> Thanks, that explains it. I'm about to take off on a road-trip, or I'd
> offer to add a warning. If you can give me a hint as to where to start I
> may be able to get to it when we get back.

I don't know where exactly this is happening, but we typically build
DependentDeclRefExprs when we have an undeclared id in a template in
-fms-compatibility mode.  The name isn't actually dependent on template
arguments, but it allows us to delay lookup until template instantiation
time, which is basically what MSVC does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140804/4c23e034/attachment.html>

More information about the cfe-dev mailing list