r192494 - Adds Microsoft compatiable C++ record layout code to clang.

[Warren Hunt]

Committed as r201810.

-Warren


On Thu, Feb 20, 2014 at 12:15 PM, Warren Hunt <whunt at google.com> wrote:

> After further discussion/investigation, the check is wrong and we should
> remove it.  Without the check, if we are debugging on windows using lldb
> and DWARF, we can potentially get the wrong layout during a debugging
> session in which someone defines a new type.  Given that don't have support
> debugging on windows using lldb, this is fine.  I'll patch it.
>
> -Warren
>
>
> On Thu, Feb 20, 2014 at 6:16 AM, Will Wilson <will at indefiant.com> wrote:
>
>> Hi Warren,
>>
>> As far as I understand, a PCH is treated much like a simplified clang
>> module and as such any PCH is an ExternalSource meaning the ExternalSource
>> is valid in this case. I don't thing DWARF has any relevance here AFAIK.
>>
>> It's likely that I was seeing this "delayed" layout behaviour due to the
>> record in question being a class template declared in the PCH that wasn't
>> instantiated in the PCH but later in a compiland including the PCH. After
>> all you can't do record layout for a template class that hasn't yet been
>> instantiated (well unless all the data members weren't dependent on
>> template arguments). So even if known record layout are serialized in the
>> PCH (I don't actually know if they are or not TBH) there will always be
>> class templates instantiations that would have to be laid out after the
>> creation of the PCH - as is the case for me.
>>
>> Either way, in this case the "&& !D->getASTContext().getExternalSource()"
>> still does a layout, it just does one without using MS layout rules.
>>
>> - Will.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140220/32997a61/attachment.html>