This is an archive of the discontinued LLVM Phabricator instance.

[clang][ASTImporter] Add a 'Message' member to ASTImportError and use it throughout ASTImporter
Needs ReviewPublic

Authored by Michael137 on Jul 7 2023, 5:58 AM.

Details

Summary

This patch adds a new ASTImportError::Message which is used
to more accurately describe a failure when ASTImportError::log
is called. We then set this error message throughout ASTImporter.

The motivation for this is that in upcoming patches LLDB will
check ASTImportErrors and log them on failures. At the moment
these logs wouldn't be helpful since we wouldn't be able to
differentiate between the different conflicts that occur
during a single import process.

Diff Detail

Event Timeline

Michael137 created this revision.Jul 7 2023, 5:58 AM
Herald added a reviewer: shafik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Michael137 requested review of this revision.Jul 7 2023, 5:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 7 2023, 5:58 AM
Michael137 updated this revision to Diff 538110.Jul 7 2023, 6:00 AM
  • Remove redundant header additions

Didn't add tests for this since checking the contents of the error message didn't seem worth testing.
But don't mind adding tests if reviewers feel more comfortable

Michael137 retitled this revision from [clang][ASTImporter] Add a 'Message' member to ASTImportError use it throught ASTImporter to [clang][ASTImporter] Add a 'Message' member to ASTImportError and use it throughout ASTImporter.Jul 7 2023, 6:02 AM
Michael137 updated this revision to Diff 538111.Jul 7 2023, 6:03 AM
  • Fix commit message

The goal is to have a message always in ASTImportError? Then probably the constructor without message can be removed, at least to check if really the message is added at all places. I found that it is missing in VisitObjCImplementationDecl.
I do not know what happens with messages passed to FromDiag or ToDiag and if these are available somehow to LLDB. Otherwise it would be even better to remove all FromDiag and ToDiag messages from ASTImporter and put these messages into ASTImportError and use later in the way that is needed by the use case. This would require to pass a message to HandleNameConflict but then we have always the detailed message. There are places where diagnostic is generated but there is no error, we should check if this is correct and if we can remove the diagnostic or make import error.

The goal is to have a message always in ASTImportError? Then probably the constructor without message can be removed, at least to check if really the message is added at all places. I found that it is missing in VisitObjCImplementationDecl.

Agree, will do that

I do not know what happens with messages passed to FromDiag or ToDiag and if these are available somehow to LLDB.

Ideally yes, but I found they're not very helpful in LLDB's use-case because:

  1. the diagnostic doesn't get issued at all call-sites
  2. LLDB switches off any odr related warnings because AFAIU they occur a lot (outside the ASTImporter) and would flood the user with redundant information

Otherwise it would be even better to remove all FromDiag and ToDiag messages from ASTImporter and put these messages into ASTImportError and use later in the way that is needed by the use case. This would require to pass a message to HandleNameConflict but then we have always the detailed message. There are places where diagnostic is generated but there is no error, we should check if this is correct and if we can remove the diagnostic or make import error.

That sounds like a good way forward. The -ast-merge clang option does benefit from these diagnostics. So we would probably need to change it to dump the ASTImportError instead of relying on the diagnostics.