Constant qualifier on typeof

[Benedikt Huber]

Hi Aaron,
>>> For instance, language-c will accept the following code already:
>>>
>>> typedef int foo;
>>> const foo y;
>>>
>>> though it's not immediately obvious to me where the const  
>>> qualifier gets recorded.
>> Oh, that's a misconception in the analysis.
>> What I can see is that
>> a) type qualifiers are dropped for typedefs (tDirectType)
>> b) type qualifiers are not allowed for typedefs (mergeTypeAttributes)
>>  c) attributes are dropped for direct types altogether
I took me far too long to find time to work on this, but I finally  
have a patch fixing these three issues. The patch affects quite a lot  
of code, but has been straightforward to implement. Anyway, I hope I  
did not introduce any errors.

Tue Feb 23 19:05:54 CET 2010  Benedikt Huber
   * Add type qualifiers and attributes to SemRep.Type

   aaron:
   >> For instance, language-c will accept the following code already:
   >>
   >> typedef int foo;
   >> const foo y;
   >>
   >> though it's not immediately obvious to me where the const  
qualifier gets recorded.
   benedikt:
   > Oh, that's a [bug] in the analysis:
   > a) type qualifiers are dropped for typedefs (tDirectType) [FIXED]
   > b) type qualifiers are not allowed for typedefs  
(mergeTypeAttributes) [FIXED]
   > c) attributes are dropped for direct types altogether [FIXED]

   Other than that, the changes were mostly straightforward, still I  
hope no new bugs have been introduced.
Tue Feb 23 23:06:12 CET 2010  benedikt.huber at gmail.com
   * Fix examples to include additional typequal/attribute fields of  
SemRep.Type

I'm curiuos, how do you use the type-checking code in the analysis  
library ? Do you use a patched version of language.c ?

cheers, benedikt

>>
>>> Does anyone else have a clear understanding of how this gets  
>>> processed? Would it be straightforward to refactor the code so  
>>> that both the typeof version and direct version of the code above  
>>> would result in the same internal type structure?
>> I know roughly what to do (modify SemRep/Type, adjust affected  
>> function like derefTypeDef, fix the two function mentioned above).
>> Do you think this is the best solution ? (plus all fixes needed  
>> elsewhere)
>>
>> 335c335
>> <        DirectType TypeName TypeQuals
>> ---
>>>       DirectType TypeName TypeQuals Attributes
>> 341c341
>> <      | FunctionType FunType
>> ---
>>>     | FunctionType FunType Attributes
>> 343c343
>> <      | TypeDefType TypeDefRef
>> ---
>>>     | TypeDefType TypeDefRef TypeQuals
>
> I'm happy with this solution if you are. I'd be happy to make the  
> change myself, or I can leave it to you if you prefer.
>
> Thanks,
> Aaron