nathanchance added inline comments.
================ Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8217 + err_typecheck_convert_incompatible_function_pointer.Text>, + InGroup<DiagGroup<"incompatible-function-pointer-types-strict">>, DefaultIgnore; def ext_typecheck_convert_discards_qualifiers : ExtWarn< ---------------- aaron.ballman wrote: > samitolvanen wrote: > > aaron.ballman wrote: > > > We don't typically add new off-by-default warnings because we have > > > evidence that users don't enable them enough to be worth adding them. Is > > > there a way we can enable this warning by default for CFI compilation > > > units (or when the cfi sanitizer is enabled) so that it's only off by > > > default for non-CFI users? I don't think we have any examples of doing > > > this in the code base, so I believe this would be breaking new ground > > > (and thus is worth thinking about more, perhaps it's a bad idea for some > > > reason). > > > Is there a way we can enable this warning by default for CFI compilation > > > units (or when the cfi sanitizer is enabled) so that it's only off by > > > default for non-CFI users? > > > > I can look into it, but I'm not sure if there's a convenient way to do > > that. An alternative to this could be to enable the warning by default, but > > only actually perform the check if CFI is enabled. This way non-CFI users > > would never see the warning because this really isn't a concern for them, > > but CFI users would still get the warning without explicitly enabling it. > > Or do you think this behavior would be confusing? > Heh, sorry for not being clear, that's actually somewhat along the lines of > how I envisioned you'd implement it (we don't have a way in tablegen to tie > `DefaultIgnore` to some language options or a target). > > I was thinking the diagnostic would be left as `DefaultIgnore` in the .td > file, but we'd take note in the driver that CFI was enabled and pass > `-Wincompatible-function-pointer-types-strict` to the `-cc1` invocation. If > the user wrote `-Wno-incompatible-function-pointer-types-strict` at the > driver level, that would come *after* the automatically generated flag for > cc1 and would still disable the diagnostic in the cc1 invocation (because the > last flag wins). WDYT? I do not think that is unreasonable behavior in the generic case but specifically for the Linux kernel, kCFI is disabled by default (`CONFIG_CFI_CLANG` has to be specifically enabled) but we want to see this warning regardless of the value of that configuration so that driver authors who test with clang and automated testers are more likely to find them. As a result, if the warning is not going to be default on, we would still need to specifically enable it in our CFLAGS. I suppose your suggestion would help out folks using CFI in production though so maybe it is still worth considering doing? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136790/new/ https://reviews.llvm.org/D136790 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
