[cfe-commits] r60597 - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ include/clang/Parse/ lib/AST/ lib/CodeGen/ lib/Parse/ lib/Sema/ test/Parser/

[Douglas Gregor]

On Dec 5, 2008, at 8:25 PM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>> On Dec 5, 2008, at 8:01 PM, Sebastian Redl wrote:
>>
>>> Looks pretty good. I'm a bit worried that this approach means that  
>>> pretty much every bit of Sema code that does some kind of type or  
>>> capability checking has to be aware of template types and defer  
>>> their checking. Is this correct? If so, is there any way we can  
>>> avoid it? I'm envisioning bugs en masse that only appear in  
>>> template code.
>>
>> This is absolutely correct. Before checking whether a particular  
>> expression or declaration is valid, we will need to check whether  
>> its parts are dependent (dependent types, type-dependent  
>> expressions, value-dependent expressions, etc.).
> OK, at the very least, we need a simple way to do this  
> (Expr::isDependent()). But undoubtedly you're planning that already.

Yeah, we'll have

	Type::isDependentType()
	Expr::isValueDependent()
	Expr::isTypeDependent()

>
>> Frankly, I don't think there's any way around it.
> I was afraid of that. And I'm also afraid that we'll have yet  
> another case when we get concepts, because I don't think that  
> constrained type parameters are quite the same as concrete types. Or  
> are they?

They're similar. When type-checking in the presence of concepts, we  
treat types that would be dependent via nearly-concrete types called  
"archetypes". I believe that archetypes will fit beautifully into our  
canonical type system :)

>
>> Getting some level of template support into the compiler early  
>> perhaps means that we can be conscientious about adding template  
>> support for something as soon as we add the non-template support  
>> for it. We should try to enforce this through the type system.
> Hmm ...
>
> Anyway, it'll also need restructuring so that all the checkers can  
> be called from the template instantiator. We definitely have a lot  
> of work ahead.

Yeah, and SFINAE makes this doubly interesting, because we have to be  
able to say: oops, we hit a problem during instantiation, back out and  
be quiet about it.

>>
>> The dependent-types computation will be coming later today.
> 3 and a half hours left of today where I am, but I'm looking forward  
> to it. ;-)

I'm typing as fast as I can :)

> By the way, how does GCC do this stuff?


GCC's approach is pretty similar to what I'm planning for Clang  
because, well, GCC does it the right way. This approach gives us the  
best ASTs and the most type-checking at template definition time,  
which will put us in the right place for eventually implementing  
concepts where *everything* is type-checked at template definition time.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081205/8d53eb79/attachment.html>