[LLVMbugs] [Bug 8374] New: Generalize clang blocks to support other closure-like language features

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=8374

           Summary: Generalize clang blocks to support other closure-like
                    language features
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alp at nuanti.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang Sema and IRgen support for the Apple blocks extension can be reworked to
provide a general-purpose backend for closure-style language constructs.

In particular, Apple blocks (a) share many characteristics with (b) GNU nested
functions and (c) C++0x lambdas:
  * IRgen to privately linked LLVM function: a, b, c
  * Capture of locals by reference: a, b, c
  * Capture of locals by value: a, c
  * Permits taking address-of-function: a, b (often with undefined behavour), c

It should be possible to support GNU nested functions with a one-line
modification to the parser and potentially no new AST classes, while C++0x
lambda support will require a little additional parser support and new
Stmt/Decl classes.

While nested functions aren't a high priority, re-using Blocks IRgen would get
us support for this GNU feature with little effort while providing more
complete coverage of the gcc DG test suite, which tests many unrelated language
features using nested functions for scoping brevity.

C++0x lambdas on the other hand are a popular upcoming feature already
supported by VC++. The blocks code can be easily modified to cover most of the
semantic analysis and codegen required by the standard for lambdas. Ditto for
the static analyzer.

Another motivation for generalising the blocks code is to audit the following:

 1) BlockDeclRefExpr: Would it be possible to just use ordinary DeclRefExprs
for a more consistent AST?
 2) BlockDecl: This shares a lot in common with FunctionDecl and
ObjCMethodDecl. Would it be possible to factor out shared functionality into a
common base?
 3) Overloaded "Block" terminology in clang internals is confusing to
developers. isBlockScope(), isBlockVarDecl(): Trying to figure out whether
functions like this refer to Apple blocks or C statement blocks {} is guesswork
for anyone. "Block" already has a single, clear meaning to most compiler
developers while Apple "Blocks" are really just a marketing term for a specific
flavour of closures. Let's make this clear at the source level.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.