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

Warren Hunt whunt at google.com
Thu Feb 20 12:20:43 PST 2014

Committed as r201810.


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>

More information about the cfe-commits mailing list