Page MenuHomePhabricator

[ASTImporter] Add support for importing ChooseExpr AST nodes.

Authored by tmroeder on Feb 25 2019, 9:17 PM.



This allows ASTs to be merged when they contain ChooseExpr (the GNU
builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of

The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to

This was originally reviewed and approved in and submitted as r354832. It was
reverted in r354839 due to failures on the Windows CI builds.

This version fixes the test failures on Windows, which were caused by
differences in template expansion between versions of clang on different
OSes. The version of clang built with MSVC and running on Windows never
expands the template in the C++ test in ImportExpr.ImportChooseExpr in
clang/unittests/AST/ASTImporter.cpp, but the version on Linux does for
the empty arguments and -fms-compatibility.

So, this version of the patch drops the C++ test for
__builtin_choose_expr, since that version was written to catch
regressions of the logic for isConditionTrue() in the AST import code
for ChooseExpr, and those regressions are also caught by
ASTImporterOptionSpecificTestBase.ImportChooseExpr, which does work on

Event Timeline

tmroeder created this revision.Feb 25 2019, 9:17 PM
tmroeder updated this revision to Diff 188307.Feb 25 2019, 9:36 PM

Dropped the C++ part of the ImportChooseExpr test entirely.

This is the part that was breaking the tests on Windows, and after further experimentation, it turns out that clang on Windows never expands the template under the conditions of the test. Dropping this test doesn't reduce coverage of the logic regression discussed in the original review. This is explained in the revised summary.

tmroeder edited the summary of this revision. (Show Details)Feb 25 2019, 9:40 PM
martong added inline comments.Feb 26 2019, 1:53 AM

To compensate the skipping of the template test, perhaps we should have another expectation for the condition dependency of the expression:

EXPECT_EQ(FromChooseExpr->isConditionDependent(), ToChooseExpr->isConditionDependent());
tmroeder updated this revision to Diff 188397.Feb 26 2019, 9:32 AM

Added the other expectation, as suggested.

I'm going to submit this patch again, since that I believe I understand the problem, and I have tested this version on Win10 with the latest MSVC (other than the expectation that I just added, but that test wasn't a problem on the Windows builders, and the new expectation passes on my Linux dev box). I'll watch the Windows build at and revert if there are problems.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 26 2019, 11:26 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 26 2019, 11:26 AM
rnk added a comment.Feb 26 2019, 11:32 AM

Sounds good, thanks for debugging this.