in progress
Details
Diff Detail
Event Timeline
clang-tidy/boost/LexicalCastRedundantTypeCheck.cpp | ||
---|---|---|
48 | Now I start understanding. It looks like BuiltinTypeLoc::getLocalSourceRange() always returns a range of a single token, which doesn't work for long long, unsigned int and the like. I'm not sure whether it's reasonable to keep the information about the last token of the builtin type name in BuiltinTypeLoc, but it's possible to use lexer to work around this by looking at the tokens after the first one (see the getTokenAtLoc() function in clang-tidy/google/IntegerTypesCheck.cpp, for example). | |
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
19 | Why is the check specific to boost::lexical_cast<>? The same transformation might be equally useful for C++ named casts (like static_cast<>), a C-style cast or any other expression literally mentioning its resulting type name (e.g. llvm::cast<>, llvm::dyn_cast<>, etc.). |
clang-tidy/boost/LexicalCastRedundantTypeCheck.cpp | ||
---|---|---|
48 | Ok, I will take a look at this, but I find it very unintuive - I think that this function should also work for PODs | |
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
19 | That's right. I was planning to ship this first, because the code base which I will be testing this consists of much more lexical_cast.
And the last one would do all the job, and it would be configurable so other checks can add their casts. |
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
---|---|---|
19 | I don't think there's a significant difference in how boost::lexical_cast and llvm::(dyn_)?cast(_or_null)? should be handled. The difference is mainly in the list of function/type names. A slightly (though not too much) different case is when the type isn't completely repeated in the template parameter (e.g. const VarDecl *Matched = dyn_cast<VarDecl>(*D->decl_begin()); => const auto *Matched = dyn_cast<VarDecl>(*D->decl_begin());), but it can also be handled by the same check. Ultimately, I don't see a reason for three new checks here. I somehow like the idea to extend the already existing modernize-use-auto check instead of adding a new one. What do you think? |
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
---|---|---|
19 | That's right, but what I see from other checks, is that some of them redirects to other. The other thing is that I don't think that having modernize-use-auto looking for boost::lexical_cast is good idea. |
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
---|---|---|
19 |
A check can be registered under multiple names specifically for this purpose.
Why not? What undesirable effects can this result in? In any case, we should make the list of functions handled by modernize-use-auto configurable so we can specify a custom list of types when registering the check in a project-specific module. |
I think will be good idea to extend modernize-use-auto instead of introducing new checks, especially multiple ones. See also PR25499.
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
---|---|---|
19 | Hmm, ok, I think you are right. But I am not sure is it easy to do something like this:
I guess I would have to add some options that would switch off some things in modernize-use-auto. |
clang-tidy/boost/LexicalCastRedundantTypeCheck.cpp | ||
---|---|---|
48 | Ok, so what is the plan - should I use the same hacks as in IntegerTypesCheck, or can I fix getLocalSourceRange to give full type? |
clang-tidy/boost/LexicalCastRedundantTypeCheck.cpp | ||
---|---|---|
48 | As Richard Smith suggested, fixing getLocalSourceRange might make sense. He'd probably be the best reviewer for the change implementing that. |
clang-tidy/boost/LexicalCastRedundantTypeCheck.h | ||
---|---|---|
19 |
I think, the default one should look for the standard casts (note, they have nothing to do with STL, they are language constructs) and have an option with a list of custom cast-like functions. The aliases (say, boost-use-auto) could handle all standard cases and add boost::lexical_cast to the aforementioned list of custom cast-like functions. |
Why is the check specific to boost::lexical_cast<>? The same transformation might be equally useful for C++ named casts (like static_cast<>), a C-style cast or any other expression literally mentioning its resulting type name (e.g. llvm::cast<>, llvm::dyn_cast<>, etc.).