Displaying 3 results from an estimated 3 matches for "matcherctor".
2018 Dec 04
4
[cfe-dev] RFC: Modernizing our use of auto
...ue what type
`NodeKind` is. I think this is borderline, and I think its fine to be
somewhat subjective based on the reviewer that is more familiar with the
code and APIs in question.
> > I'd also like to update them so that
> >
> > llvm::Optional<std::pair<std::string, MatcherCtor>>
> > getNodeConstructorType(ASTNodeKind targetType) {
> > auto const &ctors = RegistryData->nodeConstructors();
> > auto it = llvm::find_if(
> > ctors, [targetType](const NodeConstructorMap::value_type &ctor) {
> > return ctor.first.isSa...
2018 Nov 25
6
RFC: Modernizing our use of auto
...he coding guidelines.
That kind of thing is coming up as Optional is used more in the
codebase, but also with objects which have a validity check such as
isNone(), isValid(), isNull() or just `!= nullptr` etc.
I'd also like to update them so that
llvm::Optional<std::pair<std::string, MatcherCtor>>
getNodeConstructorType(ASTNodeKind targetType) {
auto const &ctors = RegistryData->nodeConstructors();
auto it = llvm::find_if(
ctors, [targetType](const NodeConstructorMap::value_type &ctor) {
return ctor.first.isSame(targetType);
});
if (it == ct...
2018 Dec 31
4
RFC: Modernizing our use of auto
On Dec 16, 2018, at 11:44 AM, Stephen Kelly via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> On 25/11/2018 14:43, Stephen Kelly via llvm-dev wrote:
>> However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases.
>> Currently the rule on the use of auto is here:
>
> Hi,
>
> Thanks for the input on this topic,