[PATCH] D52136: [clang-tidy] Add modernize-concat-nested-namespaces check
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 24 13:57:00 PDT 2018
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.
Aside from the local `const` qualification stuff and some minor wordsmithing of the documentation, this LGTM.
================
Comment at: clang-tidy/modernize/ConcatNestedNamespacesCheck.cpp:52
+ const NamespaceContextVec &Namespaces) {
+ std::ostringstream Result;
+ bool First = true;
----------------
wgml wrote:
> aaron.ballman wrote:
> > wgml wrote:
> > > aaron.ballman wrote:
> > > > Can this be rewritten with `llvm::for_each()` and a `Twine` so that we don't have to use `ostringstream` (which is a big hammer for this).
> > > The main advantage of `stringstream` was that it is concise.
> > >
> > > I don't think I can effectively use `Twine` to build a result in a loop. If I'm wrong, correct me, please.
> > >
> > > I reworked `concatNamespaces` to use `SmallString` with another educated guess of `40` for capacity.
> > The `Twine` idea I was thinking of is not too far off from what you have with `SmallString`, but perhaps is too clever:
> > ```
> > return std::accumulate(Namespaces.begin(), Namespaces.end(), llvm::Twine(), [](llvm::Twine Ret, const NamespaceDecl *ND) {
> > return Ret + "::" + ND->getName();
> > }).str();
> > ```
> Yeah, I tried that, but Twine has it's `operator=` deleted.
Ugh, good catch! The current formulation is fine then, thank you!
================
Comment at: clang-tidy/modernize/ConcatNestedNamespacesCheck.cpp:31
+static bool singleNamedNamespaceChild(const NamespaceDecl &ND) {
+ const NamespaceDecl::decl_range Decls = ND.decls();
+ if (std::distance(Decls.begin(), Decls.end()) != 1)
----------------
wgml wrote:
> aaron.ballman wrote:
> > We usually only const-qualify local declarations when they're pointers/references, so you can drop the `const` here (and in several other places). It's not a hard and fast rule, but the clutter is not useful in such small functions.
> From my perspective, `const` is a easy way of declaring that my intention is only to name given declaration only for reading and to improve code readability.
I wasn't making a value judgement about the coding style so much as pointing out that this is novel to the code base and we tend to avoid novel constructs unless there's a good reason to deviate. I don't see a strong justification here, so I'd prefer them to be removed for consistency.
================
Comment at: docs/clang-tidy/checks/modernize-concat-nested-namespaces.rst:6
+
+Checks for use of nested namespaces in a form of ``namespace a { namespace b { ... } }``
+and offers change to syntax introduced in C++17: ``namespace a::b { ... }``.
----------------
in a form of -> such as
================
Comment at: docs/clang-tidy/checks/modernize-concat-nested-namespaces.rst:7
+Checks for use of nested namespaces in a form of ``namespace a { namespace b { ... } }``
+and offers change to syntax introduced in C++17: ``namespace a::b { ... }``.
+Inlined namespaces are not modified.
----------------
offers change to syntax -> suggests changing to the more concise syntax
================
Comment at: docs/clang-tidy/checks/modernize-concat-nested-namespaces.rst:8
+and offers change to syntax introduced in C++17: ``namespace a::b { ... }``.
+Inlined namespaces are not modified.
+
----------------
Inlined -> Inline
https://reviews.llvm.org/D52136
More information about the cfe-commits
mailing list