[cfe-commits] r84907 - in /cfe/trunk: include/clang/AST/ASTContext.h include/clang/AST/Type.h include/clang/AST/TypeLoc.h include/clang/AST/TypeNodes.def include/clang/Frontend/PCHBitCodes.h lib/AST/ASTContext.cpp lib/AST/Type.cpp lib/CodeGen/Mangle.cpp lib/Frontend/PCHReader.cpp lib/Frontend/PCHWriter.cpp lib/Index/ResolveLocation.cpp lib/Sema/Sema.h lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaType.cpp lib/Sema/TreeTransform.h test/SemaCXX/overloaded-operator.cpp

John McCall rjmccall at apple.com
Fri Oct 23 10:11:07 PDT 2009


Sebastian Redl wrote:
> John McCall wrote:
>> - QualType getPointeeType() const { return PointeeType; }
>> + bool isSpelledAsLValue() const { return SpelledAsLValue; }
>> +
>> + QualType getPointeeTypeAsWritten() const { return PointeeType; }
>> + QualType getPointeeType() const {
>> + // FIXME: this might strip inner qualifiers; okay?
>> + const ReferenceType *T = this;
>> + while (T->InnerRef)
>> + T = T->PointeeType->getAs<ReferenceType>();
>> + return T->PointeeType;
>> + }
> Yes, I believe this is OK. Technically, there can't be any other 
> qualifiers, since references cannot be qualified. If we accept them, 
> they're still ignored.
>
> typedef const int &IRef; // This const must be preserved
> typedef const IRef &IRefRef; // This const will get lost, but is 
> meaningless anyway.
>
> Hmm ... it might not be OK for the restrict qualifier.

We actually forbid restrict on reference types already. I'm not 
convinced this is correct, but we do it, so ignoring intermediate 
restricts doesn't seem too wrong. A diagnostic wouldn't be out of order 
— probably a SFINAE one. Wouldn't that be fun for the template 
metaprogrammers.

If we start permitting restrict references, turning unqualified 
references into restrict references through template instantiation is a 
frightening thought.

John.



More information about the cfe-commits mailing list