r206201 - Allow multiple modules with the same name to coexist in the module cache

Reid Kleckner rnk at google.com
Fri Apr 18 14:06:50 PDT 2014


Yep, thanks a lot!  I wonder if we can un-xfail the test for mingw64.


On Fri, Apr 18, 2014 at 1:48 PM, Ben Langmuir <blangmuir at apple.com> wrote:

> Actually, I think that was enough :)  I think there was already a bug
> here, wherein after some error in ASTUnit we might try to load data from
> the CI that was not created yet.  Then in the below commit I added a new
> way to hit that bug.   Hopefully fixed in r206644.
>
> Ben
>
>
>
> On Apr 18, 2014, at 11:56 AM, Reid Kleckner <rnk at google.com> wrote:
>
> On Fri, Apr 18, 2014 at 9:48 AM, Ben Langmuir <blangmuir at apple.com> wrote:
>
>>
>> On Apr 17, 2014, at 6:40 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>> Hi Ben, test/Index/pch-with-errors.c has been hitting an assertion
>> "compiler instance has no astcontext!" since this commit.  The test doesn't
>> actually fail due to the 'not' prefix on the clang command.  Any thoughts
>> on how to fix this?
>>
>>
>> Not off hand, I looked through my patch again and there is nothing
>> obvious to me that would try to use the ASTContext before it is created.  I
>> can’t reproduce this failure on my machine.  Could you send me the
>> backtrace?
>>
>
> Sure, but I doubt this will be very useful, because it's optimized and
> lacks line numbers:
> libclang!_wassert+0x589 [f:\dd\vctools\crt\crtw32\misc\assert.c @ 369]
> libclang!clang::ASTUnit::transferASTDataFromCompilerInstance+0x61
> libclang!clang::ASTUnit::Parse+0x601
> libclang!clang::ASTUnit::LoadFromCompilerInvocation+0x145
> libclang!clang::ASTUnit::LoadFromCommandLine+0x696
> libclang!clang_parseTranslationUnit2+0x8a7
> libclang!llvm::CrashRecoveryContext::RunSafely+0x66
>
> The test fails outright for me in debug mode, so I can't repro the
> assertion with a nice stack trace.  I usually build release+asserts.  This
> is the failing output:
>
> """"
> Command 6: "D:/src/llvm/build_debug/./bin\FileCheck.EXE"
> "-check-prefix=PCH-ERR"
> "D:\src\llvm\tools\clang\test\Index\pch-with-errors.c"
> Command 6 Result: 1
> Command 6 Output:
>
> Command 6 Stderr:
> D:\src\llvm\tools\clang\test\Index\pch-with-errors.c:41:13: error:
> expected string not found in input
> // PCH-ERR: error: PCH file contains compiler errors
>             ^
> <stdin>:1:1: note: scanning from here
> fatal error: malformed block record in PCH file:
> 'D:\src\llvm\build_debug\tools\clang\test\Index\Output\pch-with-errors.c.tmp.h.pch'
> ^
> <stdin>:1:33: note: possible intended match here
> fatal error: malformed block record in PCH file:
> 'D:\src\llvm\build_debug\tools\clang\test\Index\Output\pch-with-errors.c.tmp.h.pch'
>                                 ^
> """"
>
> Note that Takumi XFAILd the test on mingw64 as well in r206294, so I think
> there's an underlying problem here.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140418/45f25e98/attachment.html>


More information about the cfe-commits mailing list