================ @@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D, D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident)); } +static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) { + if (!AL.hasParsedType()) { + S.Diag(AL.getLoc(), diag::err_attribute_wrong_number_arguments) << AL << 1; + return; + } + + TypeSourceInfo *ParmTSI = nullptr; + QualType type = S.GetTypeFromParser(AL.getTypeArg(), &ParmTSI); + assert(ParmTSI && "no type source info for attribute argument"); + + if (type->isEnumeralType()) { + QualType BitfieldType = llvm::cast<FieldDecl>(D)->getType(); + QualType EnumUnderlyingType = + type->getAs<EnumType>()->getDecl()->getIntegerType(); + if (EnumUnderlyingType != BitfieldType) { ---------------- Endilll wrote:
> and only prevent situations where the specified type is not an enumeration or > integral type. > This ALSO makes me wonder if forcing it to be an enum type is necessary. I intentionally haven't been restricting the set of types that can be passed as the argument to `preferred_type`. This makes even more sense now that we are going with more generic name. I'm just making sure that enum-related diagnostics are triggered only when enum was passed by the user. > Another case we should consider would be whether we want to allow signed > unsigned mismatches: > I think in the signed/unsigned mismatch, we should allow it (thanks to the > layout rules) > 1 enum that can represent a negative value I disagree. We shouldn't pretend that our enums can hold negative values, while we store them in unsigned bit-fields (save for rare exceptions, if any). Now that we are not bound by C++98 compilers, I believe we should propagate underlying type of our enums from bit-field type they are stored in (usually `unsigned`, `uint64_t` for `DeclBase.h`), and deal with negative values at enumerator declaration (I guess we'll have to explicitly cast them to the underlying type). I can do that while adding `clang::preferred_type` to bit-fields. Ideally I'd propagate bit-field width as well, but that doesn't seem possible at the moment: https://github.com/llvm/llvm-project/pull/69104#issuecomment-1770189229 https://github.com/llvm/llvm-project/pull/69104 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits