Bug 364749 - parser support for Blocks please
Summary: parser support for Blocks please
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (Clang-based) (other bugs)
Version First Reported In: unspecified
Platform: Other All
: LO normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords: junior-jobs
Depends on:
Blocks:
 
Reported: 2016-06-25 13:17 UTC by RJVB
Modified: 2016-07-14 20:12 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Current context browser output for a block pointer argument (26.82 KB, image/png)
2016-06-28 18:10 UTC, RJVB
Details
context browser output for a block pointer with minimal support for CXType_BlockPointer (27.17 KB, image/png)
2016-06-28 18:13 UTC, RJVB
Details
code completion in Xcode (27.29 KB, image/png)
2016-06-28 18:16 UTC, RJVB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RJVB 2016-06-25 13:17:29 UTC
I'm seeing countless warnings of the type 

```
kdevelop.plugins.clang: Unhandled type: 102 void (^)()
kdevelop.plugins.clang: Unhandled type: 102 NSProgressUnpublishingHandler (^)(NSProgress *)
kdevelop.plugins.clang: Unhandled type: 102 NSProgressUnpublishingHandler (^)(NSProgress *)
kdevelop.plugins.clang: Unhandled type: 102 void (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 void (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 void (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 BOOL (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 BOOL (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 BOOL (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 BOOL (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 BOOL (^)(id, NSUInteger, BOOL *)
kdevelop.plugins.clang: Unhandled type: 102 BOOL (^)(id, NSUInteger, BOOL *)
```

which are undoubtedly due to header files from OS X system SDKs (it would help if the warning message printed the incriminated file and line number).

Would it be very hard to implement some kind of support for this CXType?
Comment 1 RJVB 2016-06-26 21:01:14 UTC
Isn't this a question of just adding a `UseKind(CXType_BlockPointer)` statement in the right place? It makes the warnings go away and gives what looks like a perfectly acceptable context browsing popup.
Comment 2 Kevin Funk 2016-06-26 21:08:31 UTC
@RJVB, please add a test to confirm & make sure it works. No time to test on OS X at this point.

See kdevelop.git:languages/clang/tests. The files/ folder contains easy-to-extend unit tests where you can add code and express the expected output directly inside code documentation blocks.
Comment 3 RJVB 2016-06-26 21:16:17 UTC
NB: blocks are not exclusive to OS X !
Comment 4 Milian Wolff 2016-06-27 09:36:38 UTC
What is a Block? Anyhow, please push a patch somewhere for review.
Comment 5 RJVB 2016-06-27 09:48:19 UTC
http://clang.llvm.org/docs/LanguageExtensions.html#blocks

I'll try to determine if a more exhaustive fix is required than simply adding a `UseKind` line and what that should be.

If a more complex implementation is indeed required, a temporary null fix would be to avoid the warning message at least on OS X, or print it only once.
Comment 6 RJVB 2016-06-27 09:53:21 UTC
btw, from https://en.wikipedia.org/wiki/Blocks_(C_language_extension):

> The block may be assigned to variables, passed to functions, and otherwise treated like a normal function pointer

That seems to suggest that it should be acceptable for the context browser to show the type as a regular function pointer, right?
Comment 7 Milian Wolff 2016-06-27 11:27:04 UTC
yes
Comment 8 RJVB 2016-06-28 18:10:01 UTC
Created attachment 99746 [details]
Current context browser output for a block pointer argument
Comment 9 RJVB 2016-06-28 18:13:31 UTC
Created attachment 99747 [details]
context browser output for a block pointer with minimal support for CXType_BlockPointer

Minimal support means adding only `UseKind(CXType_BlockPointer)` in Visitor::makeType() .
Comment 10 RJVB 2016-06-28 18:16:03 UTC
Created attachment 99749 [details]
code completion in Xcode

Xcode doesn't have an equivalent to KDevelop's context browser that pops up an informational window when hovering over a variable, argument or function. It does have "intellisense"-style code completion; this is what it shows as the suggested completion for a method taking a single block pointer argument.
Comment 11 RJVB 2016-06-28 18:19:23 UTC
I'll have to get feedback from someone more knowledgeable about this kind of syntax question.
Comment 12 Kevin Funk 2016-06-28 18:34:41 UTC
https://bugsfiles.kde.org/attachment.cgi?id=99747 looks good (enough) for me.

Feel free to push the patch adding minimal support to 5.0 branch. If you have tests, please post to Phab.
Comment 13 RJVB 2016-06-28 20:51:50 UTC
Git commit 90ea6edaf29f3ca62bba9f1d0f1be61eaf1912c5 by René J.V. Bertin.
Committed on 28/06/2016 at 20:45.
Pushed by rjvbb into branch '5.0'.

minimal parser support for block pointers, recognising them as
function pointers (good enough for a first approach). Reduces the
amount of parser warnings when scanning the system SDK headers on
Mac OS X.
Committed from host : Portia.local

M  +1    -0    languages/clang/duchain/builder.cpp

http://commits.kde.org/kdevelop/90ea6edaf29f3ca62bba9f1d0f1be61eaf1912c5
Comment 14 RJVB 2016-06-28 20:54:56 UTC
Done. 

I should have used the occasion to suggest (commit?) a bit more detailed output in the warnings about unsupported types, printing the line for instance.

Re: Phab: any ETA on integration in KDevelop?
Comment 15 RJVB 2016-07-14 20:12:30 UTC
For future reference:

"How Do I Declare A Block in Objective-C?" [http://goshdarnblocksyntax.com/]