[PATCH] D97831: [Clang][Sema] Implement GCC -Wcast-function-type

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 24 14:59:57 PDT 2021


rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

Looks good. Some possible improvements to make the diagnostic a bit more precise, but I'd be happy if you want to address some of those as follow-ups after this change.



================
Comment at: clang/lib/Sema/SemaCast.cpp:1041
+                                   ASTContext &Context) {
+  if (SrcType->isPointerType() && DestType->isPointerType())
+    return true;
----------------
I think we should also treat references like pointers here, and similarly for block pointers and ObjC pointers. Perhaps using `hasPointerRepresentation()` would make sense?


================
Comment at: clang/lib/Sema/SemaCast.cpp:1044-1048
+  // Allow integral type mismatch if their size are equal.
+  if (SrcType->isIntegralType(Context) && DestType->isIntegralType(Context))
+    if (Context.getTypeInfoInChars(SrcType).Width ==
+        Context.getTypeInfoInChars(DestType).Width)
+      return true;
----------------
ychen wrote:
> rsmith wrote:
> > In addition to allowing the cases where the sizes are the same width, should we also allow cases where the promoted types are the same width (eg, `int` versus `short`)? What does GCC do?
> GCC does exactly that. I didn't find a way to do that by looking at TargetInfo. Maybe there is a way for clang?
Hm. The right thing to do would be to call `ABIInfo::isPromotableIntegerTypeForABI`, but that's defined in `CodeGen` so we can't call it from here without violating layering. I suppose we could pull it up into the target info in `Basic`, if you're prepared to do that kind of refactoring, but maybe for now we can skip this check and emit a few warnings that GCC doesn't.


================
Comment at: clang/lib/Sema/SemaCast.cpp:1050-1055
+  llvm::DenseSet<std::pair<Decl *, Decl *>> NonEquivalentDecls;
+  StructuralEquivalenceContext Ctx(
+      Context, Context, NonEquivalentDecls, StructuralEquivalenceKind::Default,
+      false /*StrictTypeSpelling*/, false /*Complain*/,
+      false /*ErrorOnTagTypeMismatch*/);
+  return Ctx.IsEquivalent(SrcType, DestType);
----------------
ychen wrote:
> rsmith wrote:
> > I think a "same type" check (`Context.hasSameUnqualifiedType(SrcType, DestType)`) would be more appropriate here than a structural equivalence check.
> Agreed.
Taking this a bit further: we could use `hasSimilarType` to allow changes in nested cv-qualifiers. But given that we've already allowed arbitrary differences in pointee types, I suppose this would only affect pointers-to-members, and it might be preferable to allow arbitrary changes between pointer-to-member types here (except in the MS ABI case where there are meaningful differences in pointer-to-member representations between classes).

What does GCC do with differences in pointer-to-member types in function parameter types?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97831/new/

https://reviews.llvm.org/D97831



More information about the cfe-commits mailing list