[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