1. 04 11月, 2017 1 次提交
  2. 31 10月, 2017 1 次提交
  3. 24 9月, 2017 1 次提交
    • A
      Support for ref-readonly locals (#22269) · fef4159f
      Andy Gocke 提交于
      Ref-readonly locals are mostly identical to ref-readonly parameters. The
      most important difference is that when possibly mutating methods are
      called on ref-readonly locals of struct type, a proper temporary is
      created before calling the method.
      fef4159f
  4. 30 8月, 2017 1 次提交
  5. 19 1月, 2017 1 次提交
  6. 11 1月, 2017 1 次提交
  7. 09 11月, 2016 1 次提交
  8. 08 8月, 2016 1 次提交
  9. 28 6月, 2016 1 次提交
  10. 18 2月, 2016 1 次提交
  11. 14 11月, 2015 1 次提交
  12. 16 10月, 2015 1 次提交
  13. 16 9月, 2015 1 次提交
  14. 01 7月, 2015 1 次提交
  15. 28 2月, 2015 1 次提交
    • B
      Code formatter run · ae1aeb41
      beep boop 提交于
      Been almost a month since the code formatter was run so this change was
      a bit larger than would be expected for a normal (weekly) update.  Diffs
      mostly around:
      
      - Whitespace changes
      - Missing copyright headers
      - Missing visibility modifiers
      ae1aeb41
  16. 04 2月, 2015 1 次提交
  17. 15 1月, 2015 1 次提交
  18. 14 1月, 2015 1 次提交
  19. 04 10月, 2014 1 次提交
    • T
      EnC: Local variable mapping rewrite. · 916b9efa
      TomasMatousek 提交于
      Current approach and issues
      
           When emitting method body of a method updated during EnC the compiler needs to assign local variables the same slots they had before the edit, so that state stored in those locals gets preserved.
           To implement this slot mapping we used to encode information into synthesized variable names that identified the syntax node that produced the variable and ultimately allowed us to calculate the slot mapping.
           For user variables we identified the slot by name. In both cases we relied on an assumption that the compiler assigns slots in syntax order. This assumption is false in some cases. We could make it true but the requirement would be fragile and hard to enforce when new features are implemented in the compiler since the entire lowering pipeline would need to preserve the assumption.
      
           New approach
           In the new approach we calculate a "syntax offset" for each user-defined and long-lived synthesized variable. Every such variable symbol has to be associated with a syntax node (its declarator). In usual cases this is the textual distance of the declarator from the start of the method body. It gets a bit complicated when the containing method body is not contiguous (constructors). If the variable is in the body of the constructor the definition of syntax offset is the same. If the variable is defined in a constructor  initializer or in a member initializer (this is only possible when declaration expressions or closures in primary constructors are involved) then the distance is a negative sum of the widths of all the initializers that succeed the declarator of the variable in the emitted constructor body plus the relative offset of the declarator from the start of the containing initializer.
      
           If a single node is a declarator for multiple variables of the same synthesized kind (it can only happen for synthesized variables) we calculate additional number "ordinal" for such variable. We assign the ordinals to the synthesized variables with the same kind and syntax offset in the order as they appear in the lowered bound tree. It is important that a valid EnC edit can't change the ordinal of a synthesized variable. If it could it would need to be assigned a different kind or associated with a different declarator node.
      
           To support EnC of async method we will assign another number "subordinal" to certain synthesized locals (produced by spilling by-ref variables) to simplify the mapping. Assigning of such number is not yet implemented in this change.
      
           Together (syntax offset, ordinal, subordinal) form a LocalDebugId of a variable. Since this id needs to be stored in PDB for both user-defined and long-lived synthesized variables we can’t encode it in the name of the variable (the names of user-defined variables have to be their user specified names). Therefore this change introduces a new custom debug info record that is associated with a method. The record encodes the kind and id for each local slot of the method.
      
           As a consequence we no longer emit names for synthesized long-lived variables (“CS$...”) unless it’s necessary for backward comp with Dev12 EE (only display class local names need to be emitted for this reason). (changeset 1348066)
      916b9efa
  20. 25 9月, 2014 1 次提交
  21. 12 7月, 2014 1 次提交
    • T
      To support EnC well the compiler needs to carefully distinguish between... · d4b0a867
      TomasMatousek 提交于
      To support EnC well the compiler needs to carefully distinguish between long-lived and short-lived synthesized variables. Long-lived variables may cross sequence points and thus need to be mapped the the corresponding variables in the previous generation when emitting EnC deltas. Short-lived local variables shall never cross sequence points.
      
      This change revisits helpers that create synthesized variables and assigns each synthesized variable a SynthesizedLocalKind. Negative kind values are reserved for short-lived variables, positive values for long-lived variables.
      
      The change removed the option to give a synthesized variable an explicit name. The names of the variables are assigned at code-gen time based on their SynthesizedLocalKind. This is to enforce that the names of long-lived variables follow a naming pattern that allows use to reverse-engineer the SynthesizedLocalKind value from the variable name.
      
      Also renames DebugInformationKind.PDBOnly to DebugInformationKind.PdbOnly to follow .NET naming guidelines.
       (changeset 1293017)
      d4b0a867
  22. 20 6月, 2014 1 次提交
    • T
      Splits Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.CSharp and... · fc3b332f
      TomasMatousek 提交于
      Splits Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.VisualBasic into portable and desktop assemblies.
      
      Existing Core\Source, CSharp\Source and VisualBasic\Source directories are renamed to Core\Portable, CSharp\Portable and VisualBasic\Portable.
      New sibling Desktop folders are added and non-portable source is moved there.
      "System.Runtime" references has to be removed in order for the portable project system magic to automatically add facade references.
       (changeset 1281686)
      fc3b332f
  23. 08 4月, 2014 1 次提交
  24. 19 3月, 2014 1 次提交