aaron.ballman added a comment.
In D122895#3512341 <https://reviews.llvm.org/D122895#3512341>, @aaron.ballman
wrote:
> I think the current behavior today makes sense but we should see if we can
> improve it to make *more* sense. With `-Wstrict-prototypes`, we should
> complain about the block without a prototype, but the use at the call site is
> not declaring a conflicting declaration nor is it a call to a function
> without a prototype but passes arguments (both of those are
> `-Wdeprecated-non-prototype` warnings). Instead, it's a new kind of situation
> that we may want to consider adding additional coverage for under
> `-Wdeprecated-non-prototype` based on the same reasoning we used for
> diagnosing calls to a function without a prototype but pass arguments. This
> is not specific to blocks, consider:
>
> void func(void (*fp)());
> void do_it(int i);
>
> int main(void) {
> func(do_it); // It'd be nice to diagnose this too, but we don't today
> }
Mostly as a note to myself (but others can definitely chime in if they think
I'm wrong here), I *think* the correct way to handle both blocks and function
pointers is to add new `AssignConvertType` enumerators for
`IncompatibleC2xFunctionPointer` and `IncompatibleC2xBlockPointer` to represent
an assignment conversion that is compatible today but will be incompatible in
C2x. Then functions like `checkPointerTypesForAssignment()` and
`checkBlockPointerTypesForAssignment()` can return the new value, which
`DiagnoseAssignmentResult()` can use to determine whether to diagnose a
potential behavior change or not.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D122895/new/
https://reviews.llvm.org/D122895
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
