1. 01 10月, 2015 1 次提交
    • A
      Improve compiler behavior around stack overflow caused by long binary expressions. · 12be92ba
      AlekseyTs 提交于
      Fixes #5395.
      
      Adjusted Binder, Optimizer, Flow Analysis, code generator and majority of bound tree visitors to not use recursion to handle binary expressions nested on the left side of another binary expression.
      Adjusted majority of bound tree visitors to detect that stack overflow is about to happen while an expression is being traversed and report a diagnostic pointing to the expression at fault instead of crashing compiler.
      12be92ba
  2. 10 9月, 2015 2 次提交
  3. 22 8月, 2015 1 次提交
  4. 21 7月, 2015 1 次提交
  5. 17 7月, 2015 1 次提交
  6. 15 7月, 2015 2 次提交
  7. 11 7月, 2015 1 次提交
  8. 07 7月, 2015 2 次提交
  9. 03 7月, 2015 1 次提交
  10. 02 7月, 2015 2 次提交
  11. 23 6月, 2015 1 次提交
  12. 20 6月, 2015 2 次提交
  13. 09 6月, 2015 5 次提交
  14. 16 5月, 2015 1 次提交
  15. 14 5月, 2015 2 次提交
  16. 13 5月, 2015 1 次提交
  17. 07 5月, 2015 1 次提交
    • W
      Setting next statement inside a scope with a lambda cause NRE · dfdc94b6
      Wonseok Chae 提交于
      This happens since setting next statement skips the closure initialization, which marks as hidden sequence point.
      
      In this PR, we emit a regular sequence point instead of a hidden sequence point to closure initialization whenever necessary, so IP move won't skip closure initialization.
      dfdc94b6
  18. 03 5月, 2015 1 次提交
  19. 29 4月, 2015 1 次提交
  20. 16 4月, 2015 1 次提交
  21. 15 4月, 2015 1 次提交
  22. 08 4月, 2015 1 次提交
    • K
      Fix variable capturing for VB lambdas in EE... · 4dadaf52
      Kevin Halverson 提交于
      Variables may have been captured by lambdas in the original method
      or in the expression, and we need to preserve the existing values of
      those variables in the expression. This requires rewriting the variables
      in the expression based on the closure classes from both the original
      method and the expression, and generating a preamble that copies
      values into the expression closure classes.
      
      Consider the original method:
      ```
      Shared Sub M()
          Dim x, y, z as Integer
          ...
          F(Function() x + y)
      End Sub
      ```
      and the expression in the EE: "F(Function() x + z)".
      The expression is first rewritten using the closure class and the local
      `<1>` from the original method: F(Function() `<1>`.x + z)
      Then lambda rewriting introduces a new closure class that includes
      the locals `<1>` and z, and a corresponding local
      `<2>`: F(Function() `<2>`.`<1>`.x + `<2>`.z)
      And a preamble is added to initialize the fields of `<2>`:
      ```
          <2> = New <>c__DisplayClass0()
          <2>.<1> = <1>
          <2>.z = z
      ```
      4dadaf52
  23. 07 4月, 2015 1 次提交
  24. 05 4月, 2015 1 次提交
  25. 25 3月, 2015 1 次提交
  26. 17 3月, 2015 2 次提交
  27. 06 3月, 2015 1 次提交
  28. 01 2月, 2015 1 次提交
    • B
      Complete the style update to the rest of Open\src directory · 995eb372
      beep boop 提交于
           Background:
      
           As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.
      
           https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style
      
           The coding style transition is automated using a Roslyn based rewrite tool:
      
           https://github.com/dotnet/codeformatter
      
           This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.
      
           Note: this is a soft style requirement. There are no build errors that come from this change.
       (changeset 1408227)
      995eb372
  29. 31 1月, 2015 1 次提交
    • T
      EnC support for lambdas & closures in C# compiler · ebc795d4
      TomasMatousek 提交于
      1) Change MethdCompiler.BindMethodBody to associate correct syntax with BoundBlocks it creates when binding constructor with constructor initializer call (two bound blocks are created – outer one defines a closure scope for constructor parameters, the inner one defines a closure scope for variables in the body).
      2) Introduce MethodDebugId – a method ordinal and generation ordinal pair
      3) Introduce LamdbaDebugInfo and ClosureDebugInfo to represent information (syntax offset) we use to figure out how to map lambdas and closures to the previous generation.
      4) Adds a new PDB CDI record (#7) to store lambda and closure debug info.
      5) Generalizes CalculateLocalSyntaxOffset to handle positions in field/property initializers and constructor initializers. Use it to calculate syntax offsets of lambdas and closure scopes. (TODO: rename CalculateLocalSyntaxOffset to CalculateSyntaxOffset).
      6) Replace lambda and scope ordinal dispenser integers with array builders that collect LambdaDebugInfo and ClosureDebugInfo.
      7) Use TryGet- pattern for all VariableSlotAllocator APIs.
      8) Implements mapping of lambda method and display class names to previous generation via VariableSlotAllocator.
       (changeset 1407240)
      ebc795d4