Page MenuHomePhabricator

[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs.
ClosedPublic

Authored by teemperor on Feb 13 2020, 3:54 AM.

Details

Summary

When importing the main FileID the ASTImporter currently gives it no include location. This means
that any SourceLocations produced for this FileID look to Clang as if they are coming from the
main FileID (as the main FileID has no include location).

Clang seems to expect that there is only one main FileID in one translation unit (which makes sense
during normal compilation), so this behavior leads to several problems when producing diagnostics,
one being that when calling SourceManager::isBeforeInTranslationUnit on two SourceLocations
that come from two different ASTContext instances, Clang fails to sort the SourceLocations as
the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes
with "Unsortable locations found" in this function.

This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include
location. This allows Clang to sort all imported SourceLocations as now all include chains point
to the main FileID of the To ASTContext. The exact include location is currently set to the start
of the To main file (just because that should always be a valid SourceLocation).

Diff Detail

Event Timeline

teemperor created this revision.Feb 13 2020, 3:54 AM
Herald added a reviewer: shafik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
martong accepted this revision.Feb 13 2020, 5:39 AM
martong added a reviewer: balazske.
martong added a subscriber: balazske.

Looks good to me! Thanks!
Adding @balazske as another reviewer though. He worked on something related to this, where we also experienced an assert in isBeforeInTranslationUnit.

This revision is now accepted and ready to land.Feb 13 2020, 5:39 AM

Looks good to me! Thanks!
Adding @balazske as another reviewer though. He worked on something related to this, where we also experienced an assert in isBeforeInTranslationUnit.

IIRC the analyser is using the isBeforeInTranslationUnit for the error paths so that's how the X-TU analysis could hit this situation (if the error path is spanning Decls from different files). But that's mostly speculation.

Looks good to me! Thanks!
Adding @balazske as another reviewer though. He worked on something related to this, where we also experienced an assert in isBeforeInTranslationUnit.

IIRC the analyser is using the isBeforeInTranslationUnit for the error paths so that's how the X-TU analysis could hit this situation (if the error path is spanning Decls from different files). But that's mostly speculation.

Yes exactly, but we actually use the SourceLocation from the "From" unit, we have a mapping in CrossTranslationUnitContext for that purpose. See CrossTranslationUnitContext::getImportedFromSourceLocation (and https://reviews.llvm.org/D64554 and https://reviews.llvm.org/D64638)

shafik accepted this revision.Feb 13 2020, 10:26 AM
a_sidorin accepted this revision.Feb 13 2020, 1:44 PM

Nice solution!

@balazske Do you see any problems with this patch?

@balazske Do you see any problems with this patch?

I have no opinion against the change. Probably sorting order of imported source locations makes not much sense (specially if recursive imports happen) and I can not tell what is the consequence of this, maybe no problem (there was something that triggered this crash, does this way of sorting order give some usable results?).

@balazske Do you see any problems with this patch?

I have no opinion against the change. Probably sorting order of imported source locations makes not much sense (specially if recursive imports happen) and I can not tell what is the consequence of this, maybe no problem (there was something that triggered this crash, does this way of sorting order give some usable results?).

Before this patch we would get a Clang crash in SourceManager::isBeforeInTranslationUnit when emitting diagnostics that cover multiple (main) files. With this patch we get a normal diagnostic. The order of the note: messages is in the order in which they were encountered by LLDB but that is fine as long as the order is deterministic (I also don't see a very logical order in which they should be ordered and we're fine as long as the order is deterministic).

This revision was automatically updated to reflect the committed changes.