This is an archive of the discontinued LLVM Phabricator instance.

Rename APIs in unittests/AST/Language.h in preparation to share them
ClosedPublic

Authored by gribozavr on May 29 2020, 3:41 AM.

Details

Summary

Declaring these helpers in the ast_matcher namespace in the clangAST
unit test seems inappropriate -- neither these helpers, nor clangAST have
anything to do with AST matchers. Therefore, I moved these helpers to
the clang namespace.

Declaring another typedef called "ArgVector" is not a good idea -- we
already have both "ArgVector", "ArgsVector", and "ArgList". I expanded
it into the underlying type.

Declaring another enum called "Language" is not a good idea because we
arleady have the "clang::Language" enum. I renamed it to
"TestLanguage".

Similarly, I renamed "getBasicRunOptionsForLanguage" to
"getCommandLineArgsForTesting" to explain the semantics better (what are
"run options"?) and not repeat types in the function name
("ForLanguage").

Diff Detail

Event Timeline

gribozavr created this revision.May 29 2020, 3:41 AM
Herald added a reviewer: rengolin. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
gribozavr2 edited the summary of this revision. (Show Details)May 29 2020, 3:45 AM
sammccall accepted this revision.May 29 2020, 4:01 AM
sammccall added a subscriber: sammccall.

Agree with the rationale about moving the names out of clang::ast_matchers, and the names not being safe to put into clang:: as-is.

The names are a bit unwieldy though, and I wonder if all of them are patterns we want to encourage using widely (at least if so, the names become more important).

I'd consider:

  • Unittest -> Test (shorter, and unit test is two words, and llvm naming conventions notwithstanding many gtests are not unit tests)
  • moving into a clang::test namespace instead of prefixing the names
  • UnitTestClangArgs --> std::vector<std::string> it's harder to parse but much more widely understood

Anyway, don't want to block this, this is an important step to sharing which is worthwhile whether the names are my favourite or not :-)

clang/unittests/AST/Language.h
24

this enum doesn't seem great: why is the default CXX (presumably) 98? How do you get objc++ with 14 features?

(No need to address this now, but it's not clear this is a great API to spread more widely. Vs e.g.

struct TestLanguage {
  static TestLanguage CXX; // some arbitrary version
  static TestLanguage C;
  
  enum {
    CXX98,
    CXX11,
  } CXXVersion;

  vector<string> getCommandLineArgs();
}
This revision is now accepted and ready to land.May 29 2020, 4:01 AM

Thank you for working on this.

moving into a clang::test namespace instead of prefixing the names

+1 for this. We could go even further: clang::test::ast or clang::unittest::ast.

clang/unittests/AST/Language.h
24

Yes I agree. However, in the ASTImporter tests we didn't need to select multiple languages for one test case (yet). I think later if we need that case then we can address this.

Just out of curiosity. In what way do you prepare to share these test? For which component are you planning to reuse this test infrastructure?

gribozavr updated this revision to Diff 267187.May 29 2020, 5:09 AM

Addressed review feedback.

  • Unittest -> Test (shorter, and unit test is two words, and llvm naming conventions notwithstanding many gtests are not unit tests)

Done.

  • UnitTestClangArgs --> std::vector<std::string> it's harder to parse but much more widely understood

Done. I also wanted to expand the typedef, but didn't do it because I didn't want to make this change controversial.

  • moving into a clang::test namespace instead of prefixing the names

Nested namespaces with names that can appear in other namespaces ("test") are a trap in C++: https://abseil.io/tips/130. This might not be a problem within the llvm-project.git code itself, but Clang is used as a library in a lot of other software.

clang/unittests/AST/Language.h
24

Oh I absolutely agree -- I think we need a way to describe a lot more than just the language standard. Feature flags (like Objective-C, delayed template parsing etc.) should compose with each other.

I'm thinking it should be somewhat similar to the LangOptions struct, but be much friendlier for unit tests, the testing library should provide a bunch of presets that imitate important platforms (for example, 32-bit Linux, 64-bit Linux, macOS, iOS, Windows with delayed template parsing etc.)

However, we have to take this one step at a time.

gribozavr updated this revision to Diff 267188.May 29 2020, 5:11 AM

Changed description.

gribozavr2 edited the summary of this revision. (Show Details)May 29 2020, 5:11 AM
gribozavr2 edited the summary of this revision. (Show Details)

Just out of curiosity. In what way do you prepare to share these test? For which component are you planning to reuse this test infrastructure?

Tests in clang/unittests/Tooling/Syntax/TreeTest.cpp have similar needs. In fact, I think pretty much all Clang unittests that start by parsing a string of source code into a translation unit need such infrastructure.

This revision was automatically updated to reflect the committed changes.

Thanks! LGTM!

Harbormaster completed remote builds in B58408: Diff 267187.