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 <[email protected]> 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. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
