Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Dec 20, 2012
  3. Dec 19, 2012
  5. Dec 04, 2012
  7. Sep 20, 2012
  9. Sep 19, 2012
  11. Sep 18, 2012
  13. Aug 30, 2012
  15. Aug 10, 2012
  17. Jul 25, 2012
  19. Jul 23, 2012
  21. Jul 04, 2012
  23. Jul 02, 2012
    • Jordan Rose's avatar
      In blocks, only pretend that enum constants have enum type if necessary. · 7dd900ed
      Jordan Rose authored 
      In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.

In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.

Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.

<rdar://problem/11662489> (again)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159591 91177308-0d34-0410-b5e6-96231b3b80d8
      7dd900ed
  25. Jun 15, 2012
  27. Jun 06, 2012
  29. Jun 04, 2012
  31. Apr 30, 2012
  33. Apr 04, 2012
  35. Mar 11, 2012
  37. Mar 01, 2012
    • Eli Friedman's avatar
      Implement "optimization" for lambda-to-block conversion which inlines the... · 23f0267e
      Eli Friedman authored 
      Implement "optimization" for lambda-to-block conversion which inlines the generated block literal for lambdas which are immediately converted to block pointer type.  This simplifies the AST, avoids an unnecessary copy of the lambda and makes it much easier to avoid copying the result onto the heap.

Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal.  With ARC, the effect is much less obvious because the lifetime of blocks is already managed.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151797 91177308-0d34-0410-b5e6-96231b3b80d8
      23f0267e
  39. Feb 22, 2012
    • Douglas Gregor's avatar
      Generate an AST for the conversion from a lambda closure type to a · ac1303ec
      Douglas Gregor authored 
      block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).

Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151131 91177308-0d34-0410-b5e6-96231b3b80d8
      ac1303ec
  41. Feb 21, 2012
  43. Feb 20, 2012
  45. Feb 18, 2012
    • Douglas Gregor's avatar
      Rewrite variable capture within lambda expressions and blocks, · 999713ee
      Douglas Gregor authored 
      eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner
captures.

This new scheme makes two passes over the capturing scope stack. The
first pass goes up the stack (from innermost to outermost), assessing
whether the capture looks feasible and stopping when it either hits
the scope where the variable is declared or when it finds an existing
capture. The second pass then walks down the stack (from outermost to
innermost), capturing the variable at each step and updating the
captured type and the type that an expression referring to that
captured variable would see. It also checks type-specific
restrictions, such as the inability to capture an array within a
block. Note that only the first odr-use of each
variable needs to do the full walk; subsequent uses will find the
capture immediately, so multiple walks need not occur.

The same routine that builds the captures can also compute the type of
the captures without signaling errors and without actually performing
the capture. This functionality is used to determine the type of
declaration references as well as implementing the weird decltype((x))
rule within lambda expressions.

The capture code now explicitly takes sides in the debate over C++
core issue 1249, which concerns the type of captures within nested
lambdas. We opt to use the more permissive, more useful definition
implemented by GCC rather than the one implemented by EDG.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150875 91177308-0d34-0410-b5e6-96231b3b80d8
      999713ee
  47. Feb 17, 2012
    • Douglas Gregor's avatar
      Rework the Sema/AST/IRgen dance for the lambda closure type's · 27dd7d96
      Douglas Gregor authored 
      conversion to function pointer. Rather than having IRgen synthesize
the body of this function, we instead introduce a static member
function "__invoke" with the same signature as the lambda's
operator() in the AST. Sema then generates a body for the conversion
to function pointer which simply returns the address of __invoke. This
approach makes it easier to evaluate a call to the conversion function
as a constant, makes the linkage of the __invoke function follow the
normal rules for member functions, and may make life easier down the
road if we ever want to constexpr'ify some of lambdas.

Note that IR generation is responsible for filling in the body of
__invoke (Sema just adds a dummy body), because the body can't
generally be expressed in C++.

Eli, please review!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150783 91177308-0d34-0410-b5e6-96231b3b80d8
      27dd7d96
  49. Feb 15, 2012
  51. Feb 14, 2012
  53. Feb 13, 2012