[PATCH] D74143: [MLIR] Adding attribute setters generation for table gen
Mehdi AMINI via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 24 12:39:03 PST 2020
mehdi_amini added a comment.
In D74143#1889818 <https://reviews.llvm.org/D74143#1889818>, @antiagainst wrote:
> In D74143#1884098 <https://reviews.llvm.org/D74143#1884098>, @mehdi_amini wrote:
>
> > In D74143#1881674 <https://reviews.llvm.org/D74143#1881674>, @antiagainst wrote:
> >
> > > To truly allow dialect writers to dictate what naming style they want to use, the dialect writer need to control what naming convention is used to generate these attribute getter methods too.
> >
> >
> > I suspect any attempt to provide such facility (switching naming convention) will hit the issue of mismatch with Traits and inherited properties: I think it will require a major change in our infrastructure to provide this.
>
>
> I don't quite see the reason. FWIW, the current way is **also** a naming convension; it can also hit the issue of mismatch with traits and inherited properties. And once that happens, the writer has no way to avoid but to change the attribute name at the moment. Providing the ability to choose actually mitigates that...
I see two entirely separated problems:
1. Naming convention with respect to collision management: this is a correctness question. The C++ language does not allow easily to "namespace" methods, we could (and should) look into ways make our scheme more robust while keeping our modularity.
2. Naming convention with respect to style guide: this is a stylistic question (CamelCase vs camelCase vs ...). This is what I was referring to: offering an Op interface that has a consistent tweak-able style does not seem easy (if doable at all to me).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D74143/new/
https://reviews.llvm.org/D74143
More information about the llvm-commits
mailing list