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 <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
