[cfe-commits] r64533 - /cfe/trunk/lib/CodeGen/CGCall.cpp

[Daniel Dunbar]

Sounds good to me! The dependency is subtle enough that making it
explicit in the type system would be very nice.

 - Daniel

On Sat, Feb 14, 2009 at 5:47 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Feb 14, 2009, at 12:52 PM, Douglas Gregor wrote:
>
>>
>> On Feb 14, 2009, at 10:08 AM, Mike Stump wrote:
>>
>>> On Feb 13, 2009, at 6:45 PM, Daniel Dunbar wrote:
>>>> x86_64 ABI: Need to use canonical types when comparing against
>>>> ASTContext types.
>>>
>>> [ thinking out loud ] Does it make sense to encode this into the type
>>> system so that we get compilation errors when people get it wrong?
>>> I've not thought about it yet, but...   we could even have a
>>> conversion operator that can canonicalize a type, if it needed to be
>>> canonical.
>
> This is an awesome idea.
>
>> We could certainly take away QualType::operator==/!= and instead force
>> everyone to use ASTContext::hasSameType . It would probably simplify a
>> bit of code, and eliminate some not-yet-uncovered bugs that would show
>> up with gratuitous typedef'ing.
>
> I think it is a little bit deeper than that.  A more common sort of
> bug is something like:
>
> if (isa<FunctionType>(SomeType))
>
> When SomeType is not known to be canonical.  We currently use the -
>  >isFunctionType() methods to work around this.
>
>> I've also considered doing the same thing with
>> QualType::getCVRQualifiers, since this doesn't give you all of the
>> cvr-
>> qualifiers unless you already have the canonical type. I've come
>> across a few places where we've made this mistake.
>
> Right.
>
> It would be very interesting to introduce new CanQualType class.
> "getcanonicaltype" would take a QualType and return a CanQualType.
> The "isa" methods would only work on CanQualType's, as would the CVR
> qualifier query methods.
>
> Clients that really did want to get the "pretty" structure of a
> QualType could use isa<FunctionType>(Ty.getTypePtr()) for example.
> QualType and CanQualType would both be simple wrappers around a
> bitmangled pointer, so I don't think there would be any inherent
> cost.  Doing this would also expose a *lot* of subtle problems I'm
> sure, which would be a great thing.
>
> Do you see any potential problems with this?
>
> -Chris
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>