1. 29 12月, 2016 1 次提交
  2. 20 10月, 2016 1 次提交
    • A
      Run iterator validation for all block binding (#14555) · bed95961
      Andy Gocke 提交于
      Previously iterator validation was only run in MethodCompiler
      for blocks which pass through that code path, resulting in missed
      local functions inside lambda blocks, which don't pass through
      BindMethodBody.
      
      Fixes #13937
      bed95961
  3. 19 10月, 2016 1 次提交
    • N
      Breakpoint and instrumentation support for new C# 7 language features (#14535) · 61cfacab
      Neal Gafter 提交于
      * Enable finding the breakpoint location for a pattern switch case (#14426)
      Fixes #12378
      * Tests for IDE breakpoints for deconstruction foreach statement
      Fixes #14439
      * Implement and test sequence and break points for deconstruction foreach
      Fixes #14439
      * Implement and test sequence and break points for expression-bodied ctor, dtor, and accessors
      Fixes #14438
      * Enable setting a breakpoint in a local function
      Fixes #14437
      * Add support for /instrument codecoverage for new language features
      Fixes #14337
      61cfacab
  4. 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
  5. 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
  6. 15 1月, 2015 1 次提交
  7. 14 1月, 2015 1 次提交
  8. 07 1月, 2015 1 次提交
  9. 18 11月, 2014 1 次提交
    • P
      Refactor some ad-hoc bitflag manipulation in the C# compiler. · 4bcbca85
      pgavlin 提交于
      There are a number of places in the C# compiler that use packed bitfields to store various pieces of data efficiently. Each of these places had its own style for manipulating these fields, and the manipulation was typically spread throughout the containing type ad-hoc. I've centralized each set of flags and applied a more uniform style in an attempt to make things more maintainable.
      
      Note that this change fixes two existing bugs and helps guard against some potential bugs:
          - PEParameterSymbol.SetWellKnownAttribute was using ThreadSafeFlagOperations.Clear instead of ThreadSafeFlagOperations.Set, so well known attribute presence was never cached. This was not a correctness issue, but there may be a small perf improvement with the fix.
          - PEMethodSymbol was not using enough bits to store an arbitrary MethodKind.
          - Various types were using "(bitfield & bitmask) >> bitshift" to read parts of their bitfields. Because these fields must be typed as int (for ThreadSafeFlagOperations), ">>" is an arithmetic shift, so this expression may return an unexpected value if the value to be read out includes the MSB. All bitfield readout has been updated to use "(bitfield >> bitshift) & bitmask" instead.
      ***NO_CI***
       (changeset 1373181)
      4bcbca85
  10. 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
  11. 15 8月, 2014 1 次提交
    • T
      Replaces CompilationOptions.Optimize and... · 9fbe1432
      TomasMatousek 提交于
      Replaces CompilationOptions.Optimize and CompilationOptions.DebugInformationKind with a single enum OptimizationLevel that has two values: Release and Debug.
      Removes dependency in IL generation on whether PDB stream is passed to Emit or not. IL shall only differ between Release and Debug.
      
      Command line arguments /optimize, /debug and /pdb remain the same, their values map to either Release or Debug. The value of /optimize is mapped to Release or Debug. /debug+, /debug:full and /debug:pdbonly have all the same effect - enable generating PDB file. They don't influence the generated IL.
      
      Debug information/instrumentation (sequence points, dead stores, nops, etc.) doesn't need to be emitted for synthesized methods that don't contain user code (property GenerateDebugInfo on a symbol returns true).
      
      During lowering always create bound sequence nodes. In some scenarios (PDB stream is not passed, we are emitting helper that contains no user code) these nodes are not used. However, in mainstream scenarios we always emit PDBs, so optimizing the bound nodes away is optimizing for uncommon case and just increases test matrix. Lambda, iterator and async lowering have to handle presence of bound sequence point nodes. We get more test coverage if they are always present.
      
      Another reason why to always create bound sequence points is to avoid complexity and ambiguity when checking if a symbol needs debug information. Some symbols might need debug information during some lowering phases but not other. For example, the generated body of a method symbol that represents an async kick-off method doesn't need debug information since it doesn't contain any user code. However, all source code contained in an async method should have debug information emitted. Bound tree for such code is lowered in the context of the async method symbol, so the value of GenerateDebugInfo for the async method symbol would need to differ depending on which phase of compilation are we in.
      
      Finally, IL body deduplication can always be enabled (in Release and Debug), even in EnC scenarios. Removing another compiler knob further simplifies testing.
       (changeset 1316430)
      9fbe1432
  12. 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
  13. 25 3月, 2014 1 次提交
  14. 21 3月, 2014 1 次提交
  15. 19 3月, 2014 1 次提交