[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