Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
70 ms | x64 windows > LLVM.CodeGen/XCore::threads.ll |
Event Timeline
clang-tools-extra/clang-tidy/ClangTidyOptions.h | ||
---|---|---|
176–179 | If you're refactoring ctors anyway, perhaps add explicit to all of them? (The only reason to have a non-explicit ctor is if you want to enable callers to write DefaultOptionsProvider d = {gopt, opt}; instead of auto d = DefaultOptionsProvider(gopt, opt);.) But this would be scope creep, of course. | |
225 | I'd strongly recommend doing these two signatures in exactly the same way as you've done the others: pass by value and std::move out of it. Pass-by-rvalue-reference should be reserved for arcane stuff like hand-written move-constructors. You don't need pass-by-rvalue-reference here. |
clang-tools-extra/clang-tidy/ClangTidyOptions.h | ||
---|---|---|
176–179 | explicit/non-explicit doesn't really affect much here. These constructors are only used for constructing base classes or forwarding args to std::make_unique. | |
225 | While I agree that rvalues in constructors is usually suspicious, in this case it does make sense. |
clang-tools-extra/clang-tidy/ClangTidyOptions.h | ||
---|---|---|
225 | Well, IMHO it's better to just pass by value (for clarity). But it doesn't matter much either way. IMHO the "performance" angle doesn't matter because optimizing compilers, so basically at this point we're trading off "code clarity" versus "amount of bikeshedding in this PR," and I'm certainly willing to stop my bikeshedding, either way. :) |
If you're refactoring ctors anyway, perhaps add explicit to all of them? (The only reason to have a non-explicit ctor is if you want to enable callers to write DefaultOptionsProvider d = {gopt, opt}; instead of auto d = DefaultOptionsProvider(gopt, opt);.) But this would be scope creep, of course.