[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 dgregor at apple.com
Fri Dec 5 11:18:46 PST 2008


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

> Douglas Gregor wrote:
>> Author: dgregor
>> Date: Fri Dec  5 12:15:24 2008
>> New Revision: 60597
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=60597&view=rev
>> Log:
>> Representation of template type parameters and non-type template
>> parameters, with some semantic analysis:
>>  - Template parameters are introduced into template parameter scope
>>  - Complain about template parameter shadowing (except in Microsoft  
>> mode)
>>
> 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.). Frankly, I don't think there's any  
way around it. 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.

The dependent-types computation will be coming later today.

>>     // If this scope is a function or contains breaks/continues,  
>> remember it.
>> -    if (Flags & FnScope)       FnParent = this;
>> -    if (Flags & BreakScope)    BreakParent = this;
>> -    if (Flags & ContinueScope) ContinueParent = this;
>> -    if (Flags & BlockScope)  BlockParent = this;
>> -    +    if (Flags & FnScope)       	    FnParent = this;
>> +    if (Flags & BreakScope)    	    BreakParent = this;
>> +    if (Flags & ContinueScope) 	    ContinueParent = this;
>> +    if (Flags & BlockScope)    	    BlockParent = this;
>> +    if (Flags & TemplateParamScope) TemplateParamParent = this;
>>     DeclsInScope.clear();
>>
> Who let the tabs in the house? :-)

Ugh, sorry. For various reasons that cause me trauma, I'm stuck using  
a badly-configured emacs within a terminal. ARGH!

>> +  if (PrevDecl && isTemplateParameterDecl(PrevDecl)) {
>> +    // Maybe we will complain about the shadowed template parameter.
>> +    InvalidDecl +      = InvalidDecl ||  
>> DiagnoseTemplateParameterShadow(D.getIdentifierLoc(), +						        
>> PrevDecl);
>> +    // Just pretend that we didn't see the previous declaration.
>> +    PrevDecl = 0;
>> +  }
>>
> Wouldn't that be better formatted by breaking before or after the ||?

Yeah.

> At least there are a lot of tabs in the final line. Your editor  
> settings seem to be messed up.


Oh, you can't imagine how message up they are! I'll try to fix...

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


More information about the cfe-commits mailing list