================
@@ -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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits