[cfe-dev] [ASTImporter][CrossTU] inconsistent enumerators
Rafael·Stahl via cfe-dev
cfe-dev at lists.llvm.org
Thu May 3 06:58:21 PDT 2018
Sorry I didn't notice that patch because of badly set up mail filters.
I have tested my repro with trunk and the issue is resolved.
Thanks!
On 03.05.2018 15:12, Aleksei Sidorin wrote:
> Hi Rafael,
>
> This should already be fixed in upstream:
> https://reviews.llvm.org/D44079, https://reviews.llvm.org/rL330704. Or
> is it still possible to reproduce the issue?
>
>
> 03.05.2018 16:00, Rafael·Stahl пишет:
>>
>> Hello Aleksei,
>>
>> Since everything has landed on trunk now, even with command line
>> interface for CTU in clang, you can now "just launch clang" :)
>>
>> I have attached the configured project again with a run script
>> containing the command reproducing the error.
>>
>> Hope this helps!
>>
>> Regards
>> Rafael
>>
>>
>> On 04.12.2017 17:57, Rafael·Stahl via cfe-dev wrote:
>>>
>>> Hello Aleksei,
>>>
>>> Thank you for looking into this.
>>>
>>> Find attached a project of the files I mentioned in my initial
>>> report. If you check out something like r318000 and apply the
>>> current CTU patch ( https://reviews.llvm.org/D30691 Diff11 is
>>> current as of writing), the issue should be visible.
>>>
>>> @Gábor Since I run the analyzer from a custom library: Can you tell
>>> Aleksei how to run scan-build on the project? As far as I understand
>>> it should be possible with the current patch, right?
>>>
>>> Regards
>>> Rafael
>>>
>>> On 03/12/17 19:22, Aleksei Sidorin wrote:
>>>> Hello guys,
>>>>
>>>> Do you have a reprocase I can just launch clang against? I have
>>>> some ideas but ASTMerge and clang-import-test infrastructures are
>>>> not very suitable for testing CSA XTU import strategy.
>>>>
>>>>
>>>> 16.11.2017 19:42, Gábor Horváth via cfe-dev пишет:
>>>>> Hi Rafael!
>>>>>
>>>>> Yeah, the cross TU patch is a great way to detect issues with the
>>>>> ASTImporter and unfortunately, those issues are extremely hard to
>>>>> debug.
>>>>>
>>>>> Here, it looks like the source of the problem is that, when we
>>>>> import an EnumConstantDecl, we will import the EnumDecl without
>>>>> the typdef part.
>>>>> A dirty quick fix for this particular case:
>>>>>
>>>>> @@ -1782,6 +1807,11 @@ Decl
>>>>> *ASTNodeImporter::VisitEnumConstantDecl(EnumConstantDecl *D) {
>>>>> DeclarationName Name;
>>>>> SourceLocation Loc;
>>>>> NamedDecl *ToD;
>>>>> + auto *ED = cast<EnumDecl>(D->getDeclContext());
>>>>> + if (auto *TND = ED->getTypedefNameForAnonDecl()) {
>>>>> + if (!Importer.Import(TND))
>>>>> + return nullptr;
>>>>> + }
>>>>> if (ImportDeclParts(D, DC, LexicalDC, Name, ToD, Loc))
>>>>> return nullptr;
>>>>> if (ToD)
>>>>>
>>>>> I did not have time yet to deep dive into this and look at what
>>>>> the proper solution would be. Are you willing to continue to
>>>>> investigate this?
>>>>>
>>>>> Regards,
>>>>> Gábor
>>>>>
>>>>> On 13 November 2017 at 12:16, Rafael·Stahl via cfe-dev
>>>>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>>>
>>>>> Deal all
>>>>>
>>>>> While using the static analyzer with cross translation unit
>>>>> support ( https://reviews.llvm.org/D30691
>>>>> <https://reviews.llvm.org/D30691> ), I stumbled upon an issue
>>>>> that is most likely related to the ASTImporter.
>>>>>
>>>>> I'm using a custom checker, but this should be reproduced by
>>>>> just running the scan-build tool.
>>>>>
>>>>> A simple reproducing example:
>>>>>
>>>>> main.c:
>>>>>
>>>>> ---------------------------------------
>>>>> void foo();
>>>>> void moo();
>>>>>
>>>>> int main()
>>>>> {
>>>>> foo();
>>>>> moo();
>>>>> }
>>>>> ---------------------------------------
>>>>>
>>>>> foo.c:
>>>>>
>>>>> ---------------------------------------
>>>>> #include "thing.h"
>>>>>
>>>>> void foo()
>>>>> {
>>>>> (void)THING_VALUE;
>>>>> }
>>>>>
>>>>> void conflict(thing_t type)
>>>>> {
>>>>> }
>>>>> ---------------------------------------
>>>>>
>>>>> moo.c:
>>>>>
>>>>> ---------------------------------------
>>>>> #include "thing.h"
>>>>>
>>>>> void moo()
>>>>> {
>>>>> conflict(THING_VALUE);
>>>>> }
>>>>> ---------------------------------------
>>>>>
>>>>> thing.h:
>>>>>
>>>>> ---------------------------------------
>>>>> typedef enum {
>>>>> THING_VALUE
>>>>> } thing_t;
>>>>>
>>>>> void conflict(thing_t type);
>>>>> ---------------------------------------
>>>>>
>>>>> Notes on particularities of this example:
>>>>>
>>>>> - main.c needs to NOT include the header
>>>>> - main() needs to call the functions in this order
>>>>> - foo() needs to reference the enumerator
>>>>> - the enum needs to be typedef'd
>>>>>
>>>>> If any of the above points do not apply, the issue does not
>>>>> appear.
>>>>>
>>>>> The issue:
>>>>>
>>>>> ---------------------------------------
>>>>> In file included from moo.c:1:
>>>>> thing.h:1:9: warning: type 'thing_t' has incompatible
>>>>> definitions in different translation units [-Wodr]
>>>>> typedef enum {
>>>>> ^
>>>>> thing.h:2:5: note: enumerator 'THING_VALUE' with value 0 here
>>>>> THING_VALUE
>>>>> ^
>>>>> thing.h:1:9: note: no corresponding enumerator here
>>>>> foo.c:8:6: error: external function 'conflict' declared
>>>>> with incompatible types in different translation units
>>>>> ('void (thing_t)' vs. 'void (thing_t)')
>>>>> void conflict(thing_t type)
>>>>> ^
>>>>> thing.h:5:6: note: declared here with type
>>>>> 'void (thing_t)'
>>>>> void conflict(thing_t type);
>>>>> ^
>>>>> ---------------------------------------
>>>>>
>>>>> After importing conflict(thing_t) the ASTImporter compared the
>>>>> imported one with the original by structural equivalence. This
>>>>> reveals that in the imported enum the enumerators are missing,
>>>>> causing the above error.
>>>>>
>>>>> In my real code, not this example, I was unable to dump the
>>>>> imported EnumDecl, because it eventually calls
>>>>> SourceManager::isBeforeInTranslationUnit with two
>>>>> SourceLocations from different files. Not sure if this is related.
>>>>>
>>>>> I have tried adding:
>>>>>
>>>>> for (const auto Enumerator : D->enumerators())
>>>>> D2->addDecl(Importer.Import(Enumerator));
>>>>>
>>>>> before completing the definition in
>>>>> ASTNodeImporter::VisitEnumDecl(), but that results in:
>>>>>
>>>>> exe: tools/clang/lib/AST/DeclBase.cpp:1374: void
>>>>> clang::DeclContext::addHiddenDecl(clang::Decl*): Assertion
>>>>> `!D->getNextDeclInContext() && D != LastDecl && "Decl already
>>>>> inserted into a DeclContext"' failed.
>>>>>
>>>>> I'm not familiar enough with the ASTImporter to help myself
>>>>> further here. Does anyone know what could be the issue?
>>>>>
>>>>> Best regards
>>>>> Rafael Stahl
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Aleksei Sidorin,
>>>> SRR, Samsung Electronics
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> --
> Best regards,
> Aleksei Sidorin,
> SRR, Samsung Electronics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180503/b9f528a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180503/b9f528a0/attachment.bin>
More information about the cfe-dev
mailing list