[cfe-dev] Working with ConceptClang: Binding input arguments to functions.

[Douglas Gregor]

On Apr 22, 2011, at 2:05 AM, Larisse Voufo wrote:

> Here's a basic example I've been trying to get to work:
> 
> explicit concept A<typename T> { 
>     typename AType;  
> 
>     AType h(AType a) { 
>         return a;
>     }
> 
>     AType f(AType a) { 
>         AType b;
>         return b;
>     }
> }
> 
> concept_map A<int> {
>     typedef char AType;
> } 
> 
> template<typename T>
> requires (A<T>) 
> void func(T a, AType b) {
>     AType x = h(b);         // <-- Instantiation DOES NOT WORK
>     AType y = f(b);          // <-- Instantiation WORKS
> }
> 
> int main(int argc, char **argv) 
> { 
>     func<int>(10, 'a');      // Fails with declaration for 'x', for passes with declaration of 'y'.            
> }
> 
> 
> It appears that during the instantiation of func<int>(), the value for input parameter 'b' for 'func()'
> can be looked up no problem. However, that of 'a' for associated function 'h()' cannot. 
> Instead, a call to clang::LocalInstantiationScope::getInstantiationOf() fails at runtime on the assertion:
> 
> (D->isInvalidDecl() && "declaration was not instantiated in this scope!").
> 
> I have been tracing through the procedures for building, transforming, and rebuilding Call Expressions -- as well as instantiating functions, noting each 
> execution of clang::LocalInstantiationScope::getInstantiationOf() and clang::LocalInstantiationScope::InstantiatedLocal()...
> 
> Still, I can't see what needs to be done differently for calls to h() from calls to func<int>(). Hence...
> 
> Question: 
> When/how exactly are input arguments bound to functions?

That's a runtime issue. All the front-end does is enforce the calling convention on both sides of the call.

> Why would the current procedure fail to bind the value of 'b' from the context of func<int>() to the 
> parameter 'a' of 'h()' ?

They are in completely different contexts. func<int>'s b is completely disjoint from h's a. And, in fact, they might not be the same thing, since passing 'b' as an argument to h() implies the creation of a temporary.

The only way I could see this issue coming up is if you're doing some kind of inlining of A<AType>::h into func<int> as part of instantiation. If so, I recommend against doing that: inlining will be handled by later optimization passes, and tangling the func<int> instantiation with the A<AType>::h instantiation is going to cause more problems in the front end than it solves.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110422/2a53d024/attachment.html>