This is an archive of the discontinued LLVM Phabricator instance.

[Clang-tidy] Fix some Include What You Use warnings; other minor fixes
AbandonedPublic

Authored by Eugene.Zelenko on May 26 2016, 5:55 PM.

Details

Summary

I checked this patch on my own build on RHEL 6. Regressions were OK.

Diff Detail

Repository
rL LLVM

Event Timeline

Eugene.Zelenko retitled this revision from to [Clang-tidy] Fix some Include What You Use warnings; other minor fixes.
Eugene.Zelenko updated this object.
Eugene.Zelenko added reviewers: alexfh, hokein, etienneb.
Eugene.Zelenko set the repository for this revision to rL LLVM.
Eugene.Zelenko added a subscriber: cfe-commits.
alexfh requested changes to this revision.May 27 2016, 6:55 AM
alexfh edited edge metadata.
This revision now requires changes to proceed.May 27 2016, 6:55 AM
Eugene.Zelenko edited edge metadata.

More diff content.

etienneb edited edge metadata.May 30 2016, 9:08 AM

drive-by

clang-tidy/ClangTidy.cpp
24

This one is for sure included by 'clang/Basic/Diagnostic.h'.

clang-tidy/ClangTidy.h
17

This one is for sure included by 'clang/Basic/Diagnostic.h'.

clang-tidy/ClangTidyDiagnosticConsumer.h
17

This one is for sure included by 'clang/Basic/Diagnostic.h'.

clang-tidy/ClangTidyModule.h
13

There is an issue with includes ordering here and/or line 20.

clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
15

There is always the tradeoff between including separate files, or including AST.h

I'm not sure I prefer expanding them.
alexfh? toughs?

clang-tidy/utils/OptionsUtils.cpp
1

Could you fix this 'DanglingHandleCheck.cpp' -> 'OptionsUtils.cpp'

Point of Include What You Use suggestions to rely on explicit dependencies, not implicit ones.

clang-tidy/utils/OptionsUtils.cpp
1

Will fix on commit.

Point of Include What You Use suggestions to rely on explicit dependencies, not implicit ones.

It's true most of the time.
In some case, splitting the header file is for maintainability and including the root is still the right coding-style to use.

I can't tell about what clang/llvm community will prefer. Both approaches make sense and it's matter of choice.

As an example, look to "ast.h"... there is no needs at all for the existence of that file if you only rely on your current rules.

14 #ifndef LLVM_CLANG_AST_AST_H
15 #define LLVM_CLANG_AST_AST_H
16 
17 // This header exports all AST interfaces.
18 #include "clang/AST/ASTContext.h"
19 #include "clang/AST/Decl.h"
20 #include "clang/AST/DeclCXX.h"
21 #include "clang/AST/DeclObjC.h"
22 #include "clang/AST/DeclTemplate.h"
23 #include "clang/AST/Expr.h"
24 #include "clang/AST/ExprObjC.h"
25 #include "clang/AST/StmtVisitor.h"
26 #include "clang/AST/Type.h"
27 
28 #endif

On my side, having the include statement for every AST file is over-kill.

There is a way to tell IWYU about compound headers with pragmas. I also suggested to make this possible via file with compound headers list.

But person who knows LLVM/Clang code base better then me should define such headers.

There is a way to tell IWYU about compound headers with pragmas. I also suggested to make this possible via file with compound headers list.

But person who knows LLVM/Clang code base better then me should define such headers.

I spent time thinking about that problem months ago and I've found so many strange cases.
It seems an easy problem on the surface, but when you dig you realized there is so many corner cases.

My comment on this patch is not related to the tool or how the tool is working.
It's more a question about whether or not we should "compound" some headers you expanded.
Most of the include you added are right and must be present.

A general question on your tool is: can we specify the IWYU pragma somewhere else than in the code.
I'm not in favor of building xmas tree with your header files.

IWYU pragma:

I don't know how common they will be.

Eugene.Zelenko abandoned this revision.Jul 11 2016, 1:43 PM