[PATCH] D110891: [inliner] Mandatory inlining decisions produce remarks
David Blaikie via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Oct 1 11:09:12 PDT 2021
dblaikie added inline comments.
================
Comment at: llvm/lib/Analysis/InlineAdvisor.cpp:52
+namespace {
+using namespace llvm::ore;
----------------
mtrofin wrote:
> wenlei wrote:
> > mtrofin wrote:
> > > wenlei wrote:
> > > > curious why do we need anonymous namespace here?
> > > iiuc it's preferred we place file-local types inside an anonymous namespace.
> > >
> > > Looking now at the [[ https://llvm.org/docs/CodingStandards.html#anonymous-namespaces | style guideline ]], it touts their benefits but also says I should have only placed de decl there and the impl of those members out... but the members are quite trivial. Happy to move them out though.
> > Thanks for the pointer. I don't have a strong opinion but slightly leaning towards moving out of anonymous namespace be consistent with how other InlineAdvice is organized (DefaultInlineAdvice, MLInlineAdvice not in anonymous namespace).
> Ah, those are public (i.e. in a .h file)
Generally if a type is declared/defined inside a .cpp file it should be in an anonymous namespace so it can't collide with other implementation type names in other .cpp files. (& .cpp-local functions should be static or in an anonymous namespace for the same reason)
Looks like the other two (`DefaultInlineAdvice` and `MLInlineAdvice`) are defined in headers, so they must not be in anonymous namespaces.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110891/new/
https://reviews.llvm.org/D110891
More information about the cfe-commits
mailing list