[lldb-dev] [cfe-dev] [RFC] Improving import failure checking strategy inside ASTImporter

[Gábor Márton via lldb-dev]

> But there are two issues. First, cast<> has two template arguments, not
one. Second, template instantiation cannot guess what overload of cast
should be used in each case. I'm sorry, but after a few attempts of making
this code to compile, I have to ask you to elaborate a bit more once again.

You are right, we can't just pass a template function as a template
parameter. However, we could use a lambda:
    template <typename CastOpTy, typename DeclTy>
    Optional<DeclTy *> import(CastOpTy CastOp, DeclTy *&ToD, DeclTy *FromD)
{
      if (auto Res = Importer.Import(FromD)) {
        return CastOp(Res);
      }
      return None;
    }
    template <typename DeclTy>
    Optional<DeclTy *> importNullable(DeclTy *&ToD, DeclTy *FromD) {
      return import([](Decl* R){ return cast_or_null<DeclTy>(R); }, ToD,
FromD);
    }
This approach still has disadvantages: we have to use a concrete type in
the lambda parameter (`Decl`) because polymorphic lambdas are not supported
in C++11.
So I am not sure if this is really worth it to avoid just some very few
lines of repetition.

> Regarding naming: what do you think about importNonNull[Into]() and
importNullable[Into]()?
Sounds good to me.

> There is also another thing I am curious about: do we need to use
dyn_casts on the return type? I'm not sure we can return a node with type
so different from the imported node's type. Currently, there are some
dyn_cast[_or_null]s in our code, but, possibly, they can be replaced with
just casts, because we usually return nullptr or a pointer of same type as
the imported one.
I agree. Immediately after an import I think it is perfectly legitimate to
assume that the imported node has the very same type.

Gabor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180523/3507afa5/attachment.html>