[cfe-commits] Separate semantic checking of EnumConstantDecl from the action

[Vassil Vassilev]

Hi Doug,
   Sorry I didn't give the use case. I thought that this will be only 
benefit for the compiler.

   So in our use case (in cling) we want to allow stmts "on the global 
scope" like:
   [cling$] int i =0;
   [cling$] for(...) {
   ...
   There is no easy way how we can understand whether the user input was 
declaration or stmt.
So we wrap the input internally into void cling_unique_name { body of 
stmts and decls}
For non declstmts it's all fine. However, when we have declaration the 
user expects to be visible
from the other stmts (internally wrappers).

   In that case we create a SemaConsumer that extract the declarations 
on the global scope, i.e.
change the linkage and visibility and the declaration context and we 
re-register it in the as resolver
chain if needed. Before pulling the decl out we need to make sure that 
all the c/c++ semantic rules
for that decl hold at the new position. For example, are there clashing 
names etc. If there is
something wrong we want proper diagnostic for that. In that case, 
ideally, we don't want to create yet
another AST node, which will be dangling.

   Even if we create a new node directly at the new position the old 
node will shadow the new one. Eg:
[cling$] int i; i = 15; // transformed into void cling_unique_name{int 
i; i=15;}

   I really liked the interface Sema::CheckVariableDeclaration, 
Sema::CheckFunctionDeclaration and I maybe
concluded wrongly that's the idea of all the CheckXXX functions.

I think no AST node creating CheckXXX will be reused by the template 
instantiation subsystem.
Correct me if I am wrong but right now in 
TemplateDeclInstantiator::VisitEnumDecl clang
creates redundant EnumConstantDecl because the node is created by 
Sema::CheckEnumConstant.

   Maybe I am missing something but I don't understand how this could 
make it easier to create broken AST nodes.
I guess you say that because some of the node properties are determined 
only after semantic analysis.

Can't we work this around somehow? I am willing to do the rest of the work.

Vassil

On 12/03/2011 08:43 PM, Douglas Gregor wrote:
> On Nov 30, 2011, at 6:22 AM, Vassil Vassilev wrote:
>
>> Hi,
>>   The attached patch tries to split the semantic checking from the AST node creation.
>>   I think it is useful one to be able to check already created AST node. Do you think that
>> makes sense? Can that patch end up in clang's mainline?
>
> I don't understand why you want to split this. Within Sema, we often combine semantic analysis with AST building so that there is just one place in the code that is responsible for making sure that the AST node is built with all of its invariants satisfied. Splitting semantic analysis from AST building makes it easier to create broken nodes that will cause problems downstream.
>
> 	- Doug