The code of ASTImporter::Import(const Attr *) was repetitive,
it is now simplified. (There is still room for improvement but
probably only after big changes.)
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
8516–8517 | I am enthusiastic about reference members if we can somehow avoid them. Can we use a struct to return both the Err and the pointer together? I don't like std::pair mainly b/c first and second are not meaningful. |
AttrImporter owns now the result of import (until it is read),
instead of referenced error and returned pointer.
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
8585–8586 | If it can be used only once, we should mark this function as an r-value function. Later, when you would actually call this function, you need to std::move() the object, signifying that the original object gets destroyed in the process. @aaron.ballman Do you think we need to define LLVM_RVALUE_FUNCTION or we can simply use the && in the function declaration? |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
8585–8586 | The expected pattern is: #if LLVM_HAS_RVALUE_REFERENCE_THIS void func() && { } #endif https://github.com/llvm/llvm-project/blob/main/clang/include/clang/ASTMatchers/ASTMatchersInternal.h#L609 (and elsewhere). However, I note that there are some unprotected uses (such as https://github.com/llvm/llvm-project/blob/main/clang/lib/Tooling/Syntax/BuildTree.cpp#L437) and so it may be a sign that we're fine to remove LLVM_HAS_RVALUE_REFERENCE_THIS because all our supported compilers do the right thing? |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
8585–8586 | You tried to eliminate that on Jan 22, 2020 with rGdfe9f130e07c929d21f8122272077495de531a38. |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
8585–8586 |
As am I. I went back and looked at the history here, and as best I can tell, I tried to get rid of lvalue functions, we threw it at bots, and for reasons I didn't capture anywhere I can find, had to revert it. Sorry for the troubles with not tracking that information! :-( However, in my simple testing on godbolt, I can't find a version of MSVC that has issues with lvalue or rvalue reference overloads. We claim to still support MSVC 2017 (perhaps it's time to bump that to something more recent now that MSVC has changed its release schedule), so maybe there's an older version that's still an issue, but I would expect us to have spotted that given there are unprotected uses of rvalue ref overloads. My gut feeling is that we should explore getting rid of LLVM_LVALUE_FUNCTION and LLVM_HAS_RVALUE_REFERENCE_THIS again as it's been almost two years since the last try. If there's a problematic version of MSVC, we might want to consider dropping support for it unless it persists in newer MSVC versions. |
I am enthusiastic about reference members if we can somehow avoid them.
Can we use a struct to return both the Err and the pointer together? I don't like std::pair mainly b/c first and second are not meaningful.