This is an archive of the discontinued LLVM Phabricator instance.

boost-lexical-cast-reduntant-type
AbandonedPublic

Authored by Prazek on Mar 1 2016, 6:29 AM.

Details

Reviewers
alexfh
Summary

in progress

Diff Detail

Event Timeline

Prazek updated this revision to Diff 49488.Mar 1 2016, 6:29 AM
Prazek retitled this revision from to boost-lexical-cast-reduntant-type.
Prazek updated this object.
Prazek added a reviewer: alexfh.
alexfh added inline comments.Mar 1 2016, 6:36 AM
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.).

Prazek added inline comments.Mar 1 2016, 6:48 AM
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.
Next step would be to generalize it for other casts. I am not sure how it should be, but I supose that it should not be one check doing everyhing.
I would prefer to add:

  • boost-lexical-cast-reduntant-type
  • llvm-casts-redundant-type
  • modernize-casts-redundant-type

And the last one would do all the job, and it would be configurable so other checks can add their casts.

alexfh added inline comments.Mar 1 2016, 7:08 AM
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?

Prazek added inline comments.Mar 1 2016, 7:21 AM
clang-tidy/boost/LexicalCastRedundantTypeCheck.h
19

That's right, but what I see from other checks, is that some of them redirects to other.
I think it would be nice to specify -checks=boost* and have check that would look for lexical_casts.
I have in plans to add at least one more boost check (changing lexical_cast<std::string> -> std::to_string).

The other thing is that I don't think that having modernize-use-auto looking for boost::lexical_cast is good idea.

alexfh added inline comments.Mar 1 2016, 7:36 AM
clang-tidy/boost/LexicalCastRedundantTypeCheck.h
19

I think it would be nice to specify -checks=boost* and have check that would look for lexical_casts.

A check can be registered under multiple names specifically for this purpose.

I don't think that having modernize-use-auto looking for boost::lexical_cast is good idea.

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.

Prazek added inline comments.Mar 1 2016, 11:42 AM
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:

  1. extend modernize-use-auto
  2. add boost-redundant-lexical-cast as link to modernize-use-auto, but only that would look for lexical_cast (and not iterators, new, or other things)

I guess I would have to add some options that would switch off some things in modernize-use-auto.
And I am not sure about default functions that we should match - either STL things like static_cast, dynamic_cast, reinterpret_cast
or everything with boost and llvm.

Prazek added inline comments.Mar 5 2016, 3:17 AM
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?

alexfh added a subscriber: rsmith.Apr 1 2016, 6:39 PM
alexfh added inline comments.
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.

alexfh requested changes to this revision.Apr 1 2016, 6:50 PM
alexfh edited edge metadata.
alexfh added inline comments.
clang-tidy/boost/LexicalCastRedundantTypeCheck.h
19

I guess I would have to add some options that would switch off some things in modernize-use-auto.
And I am not sure about default functions that we should match - either STL things like static_cast,
dynamic_cast, reinterpret_cast or everything with boost and llvm.

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.

This revision now requires changes to proceed.Apr 1 2016, 6:50 PM
Prazek abandoned this revision.Feb 9 2017, 11:36 AM

modernize-use-auto can handle it right now