| Summary: | parser support for Blocks please | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | RJVB <rjvbertin> |
| Component: | Language Support: CPP (Clang-based) | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | junior-jobs |
| Priority: | LO | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | All | ||
| Latest Commit: | http://commits.kde.org/kdevelop/90ea6edaf29f3ca62bba9f1d0f1be61eaf1912c5 | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: |
Current context browser output for a block pointer argument
context browser output for a block pointer with minimal support for CXType_BlockPointer code completion in Xcode |
||
|
Description
RJVB
2016-06-25 13:17:29 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. @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. NB: blocks are not exclusive to OS X ! What is a Block? Anyhow, please push a patch somewhere for review. 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. 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? yes Created attachment 99746 [details]
Current context browser output for a block pointer argument
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() .
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.
I'll have to get feedback from someone more knowledgeable about this kind of syntax question. 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. 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 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? For future reference: "How Do I Declare A Block in Objective-C?" [http://goshdarnblocksyntax.com/] |