[cfe-dev] [ASTImporter][CrossTU] inconsistent enumerators
Aleksei Sidorin via cfe-dev
cfe-dev at lists.llvm.org
Thu May 3 06:12:17 PDT 2018
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/c5ae5c97/attachment.html>
More information about the cfe-dev
mailing list