Treat 'f()' as 'f(void)' rather than a function w/o a prototype.
Details
- Reviewers
Anastasia yaxunl - Commits
- rG1f2779407e7f: [OpenCL] Allow function declaration with empty argument list.
rG3d0c97883a2a: [OpenCL] Allow function declaration with empty argument list.
rC315453: [OpenCL] Allow function declaration with empty argument list.
rC306653: [OpenCL] Allow function declaration with empty argument list.
rL315453: [OpenCL] Allow function declaration with empty argument list.
rL306653: [OpenCL] Allow function declaration with empty argument list.
Diff Detail
- Repository
- rL LLVM
Event Timeline
I kind of like this change. In reality, people often use f() as an alternative of f(void). I think diagnose it as an error is just causing inconvenience.
Yes, I also think it's useful in general. Just wondering whether we should propagate it to Khronos too since it's a deviation from either C99 or OpenCL spec.
Sorry for the delay.
It will also align the behavior with function definition.
For instance the following function definition is allowed.
__local int *allocateLocalMemory() { return 0; }
Regarding propagating this to Khronos, I'm not sure if this feature requires additional clarification in the specification.
My understanding is that it's clear that 'foo()' is equivalent to 'foo(void)'.
Do you have any particular proposal to the specification text in mind?
We could steal some text from C++? Or we can create a ticket to Khronos and see if they resolve this. Otherwise, I am also ok to keep this as Clang "extension".
Should we add cfe-commits then?
Update one more test missed in the first version of the patch.
Actually it looks like a bug in Parser.
Clang interprets following statement as variable declaration.
extern pipe write_only int get_pipe();
So the type of the pipe element is function prototype: int get_pipe().
If I understand the intention correctly, clang is expected to treat this expression function declaration with pipe return type, which elements are int.
Would it acceptable to commit this patch as is and file another bug on Parser?
I need more time to think how to resolve this ambiguity.
Ping.
Although this patch is already accepted, I'd like to confirm that I can commit the latest update with changes in test/SemaOpenCL/invalid-pipes-cl2.0.cl.
Thanks.
Sure, no problem! We might add some note on this feature to Clang manual. But we can do it later as well. Thanks!
Reverted in rL306660.
See also; http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/4926
Fix parsing of function declarations with empty parameter list initializers.
This change should fix the failure caught by the buildbot.
Sorry for the long delay.
I would prefer to merge the new test with test/SemaOpenCL/func.cl, but otherwise LGTM! Thanks!