This expands NRVO propagation for more cases:
Parse analysis improvement:
- Lambdas and Blocks with dependent return type can have their variables marked as NRVO Candidates.
Variable instantiation improvements:
- Fixes crash when instantiating NRVO variables in Blocks.
- Functions, Lambdas, and Blocks which have auto return type have their variables' NRVO status propagated. For Blocks with non-auto return type, as a limitation, this propagation does not consider the actual return type.
This also implements exclusion of VarDecls which are references to
dependent types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
We generally use FooResult to mean "either a Foo or an indicator that an error has been diagnosed". Would the name NRVOInfo work instead?
Actually, I think the "O" here is misleading, because we're not talking about performing the optimization here, just about what variable was named in a return statement. And I think calling this "NRVO" is a bit misleading because it also covers implicit move, which isn't traditionally part of NRVO. So how about NamedReturnValueInfo or NamedReturnInfo or NamedReturnValue or ReturnValueName or something like that?