1. 14 10月, 2015 1 次提交
  2. 11 10月, 2015 1 次提交
  3. 30 8月, 2015 1 次提交
  4. 12 8月, 2015 2 次提交
  5. 17 7月, 2015 1 次提交
  6. 18 6月, 2015 1 次提交
  7. 10 6月, 2015 1 次提交
  8. 05 6月, 2015 1 次提交
  9. 12 5月, 2015 1 次提交
  10. 29 3月, 2015 1 次提交
  11. 25 2月, 2015 1 次提交
  12. 18 2月, 2015 1 次提交
  13. 14 2月, 2015 1 次提交
    • A
      Reduce VM usage in emit tests · 3fcf7bac
      Andy Gocke 提交于
      This change reduces the VM used and memory allocated in the emit
      tests by moving the WinRT tests to their own DLL and removing
      the extra mscorlib reference.
      
      The cause of most of the allocations in the Emit unit tests was
      serializing the WinRT assemblies across app domains. There were
      three reasons the DLLs needed to be serialized:
      
      1) PeVerify currently requires a separate app domain to be used if
         any of the references of the assembly to be verified have already
         been loaded into the current app domain and have a different MVID.
      
      2) The WinRT tests all use a separate version of mscorlib, so they
         will all reference an assembly with a different MVID than the one
         loaded.
      
      3) Most of the WinRT tests were accidentally pulling two references
         to mscorlib, also always leading to a conflict.
      
      All of these issues should be resolved. The CSharp.Emit unit tests
      now allocated 400 MB less and have > 100 MB smaller peak VM.
      
      Fixes #386.
      3fcf7bac
  14. 12 2月, 2015 1 次提交
  15. 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
  16. 15 1月, 2015 1 次提交
  17. 14 1月, 2015 1 次提交
  18. 09 1月, 2015 3 次提交
    • C
    • A
      Make tests passing on a non-English OS, even in presence of corresponding... · 673f18e1
      AlekseyTs 提交于
       Make tests passing on a non-English OS, even in presence of corresponding localized resources. In the process several product issues were fixed like:
           - Localized exception messages incorporated into diagnostics by command line compiler are not obeying /preferreduilang switch.
           - Some strings are loaded from resources at the time when diagnostic object is created. Resources are loaded earlier than they could be. When error message is requested, it might not be localized in accordance with the requested culture.
           - When target culture is not provided, DiagnosticInfo objects used as arguments within another diagnostic object are formatted using InvariantCulture, whereas all other arguments use current culture (as expected). Portions of the message are localized to different languages. (changeset 1392630)
      673f18e1
    • T
      Implements a new approach to generating unique synthesized member names (see... · 94711411
      TomasMatousek 提交于
      Implements a new approach to generating unique synthesized member names (see also the attached email).
      
           1) Assigns each member a "member ordinal" - the index in the members array of the containing type. The ordinal is propagated thru lowering rewriters which uses it to make generated names unique.
           2) We no longer calculate "overload ordinal" for names of state machine types, we use the member ordinal of the async/iterator method instead.
           3) Removes GenerateTempNumber from TypeCompiationState. Combination of method ordinal and other indices is used to make generated names unique:
           - Display classes use ordinal of the method containing the lambda and closure scope ordinal (unique within a method). Static display class is shared across all non-generic methods of a containing class and thus doesn't need a unique number in name (it;'s simple named "c<>").
           - Lambda methods include containing method ordinal (unless emitted to a display class whose name already includes it) and lambda ordinal (unique within a method).
           - The same for fields caching lambdas.
           - Dynamic site containers - no longer include method name in the type name, instead method ordinal is used.
      
           4) Expression compiler - rename generated type to "<>x" to avoid confusion with "<>c" static display class.
           5) Avoid replacing "." with "_" in member names, other than type names. While displaying stack frames the EE extracts method name from synthesized lambdas method names and displays it. Thus we were displaying "I_F" instead of "I.F" for explicitly implemented methods.
            In type names replace "." with "-". Replacing with "_" lead to duplicate type names in emitted assembly (2 iterator methods with names "I_F" and "I.F" - explicitly implemented iface method). (changeset 1390962)
      94711411
  19. 07 1月, 2015 1 次提交
    • V
      Bug fixes for index intializers. · 40898dd1
      VSadov 提交于
      Index expressions in the index initializers should be evaluated exactly once.
      In a case of a nested initializer, we were evaluating as many times as we have members in the RHS. That resulted in a number of bugs reported.
      
      Working on this fix revealed some more issues with params and named indices not being supported properly.
      
      Fixes #449
       (changeset 1388102)
      40898dd1
  20. 04 12月, 2014 1 次提交
  21. 17 10月, 2014 1 次提交
  22. 06 10月, 2014 1 次提交
  23. 02 10月, 2014 1 次提交
    • T
      This shelveset implements following changes to metadata reference compiler API... · 4fc808ea
      TomasMatousek 提交于
      This shelveset implements following changes to metadata reference compiler API in order to remove duplication in the public surface and prevent users from unexpected metadata lifetime issues:
      
           1) MetadataImageReference and MetadataFileReference overlap
           Currently MetadataImageReference can be constructed from a Stream. MetadataImageReference supports metadata prefetch (reading the blob into memory and close the underlying stream) as well deferred reading (no content is read until the reference is consumed during compilation). MetadataFileReference only supports deferred reading.
      
           Lifetime of MetadataFileReference is non-deterministic, the underlying file is locked until no references exist and we GC the metadata.  On the other hand, it is possible to construct MetadataImageReference in such a way that allows controlling the underlying resources deterministically.
      
           Remove MetadataFileReference, use MetadataImageReference instead.
      
           2) Lifetime management
           AssemblyMetadata and ModuleMetadata objects hold on resources and implement IDisposable. When using MetadataFileReference constructors and some MetadataImageReference constructors to create references the underlying metadata objects are created implicitly and the user doesn’t have a way to explicitly dispose them.
      
           Make MetadataImageReference constructors internal and instead add factory method GetReference on AssemblyMetadata/ModuleMetadata. The usage pattern is:
      
           using (var metadata = AssemblyMetadata.CreateFromXxx(…))
           {
               var compilation = CSharpCompilation.Create(syntaxTrees, new[] { metadata.GetReference() });
               …
           }
      
           In addition the shelveset makes MetadataImageReference internal and adds the following convenience APIs, that are not the most efficient but are very convenient, easy to discover and safe to use for customers that don’t wanna explicitly manage the lifetime of metadata objects. (changeset 1345987)
      4fc808ea
  24. 25 9月, 2014 1 次提交
  25. 19 8月, 2014 1 次提交
  26. 15 8月, 2014 4 次提交
    • T
      848633e4
    • 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
    • T
      Updates tests to use either Release or Debug. Skips tests that are broken when... · 79b5920f
      TomasMatousek 提交于
      Updates tests to use either Release or Debug. Skips tests that are broken when PDB emit is enabled. (changeset 1314373)
      79b5920f
    • T
      Reduce the variety of optimization related compilation option values used in... · f58f5ab8
      TomasMatousek 提交于
      Reduce the variety of optimization related compilation option values used in tests to: Release, DebuggableRelease and Debug.
      
      By default tests should use Release, which enables all optimizations.
      PDB tests should mostly use Debug.
      We should have targeted tests for DebuggableRelease, for optimizations that are selectively disabled to improve debuggability of release builds.
      
         (changeset 1312277)
      f58f5ab8
  27. 18 7月, 2014 1 次提交
    • T
      Adjusting conditional branches for EnC. · b0615ac8
      TomasMatousek 提交于
      For every conditional branch that consumes a value of an expression that might contain calls to user code and that jumps across user code with sequence points, we need to store the value into a synthesized named local, emit stloc and ldloc and place a hidden sequence point on the ldloc instruction. Furthermore, the synthesized local variable has to be associated with the statement syntax whose lowering produces the conditional branch so that EnC infrastructure can map the local variable defined for the branch to the previous generation.
      
      In essence this is what’s going on:
      
      [|if (F())|]
      { … true … }
      else
      { … false … }
      
      IL:
      call F()
      stloc $value
      <-- hidden sequence point -->
      ldloc $value
      brfalse label_false
      <-- sequence point for “{“ of true-block -->
      … true …
      br label_end
      label_false:
      <-- sequence point for “{“of false-block -->
      … false …
      label_end:
      
      When the call to F() returns after an update has been performed on the caller the code execution continues in the old version of the caller body until a special remapping breakpoint is hit. These breakpoints are put on all sequence points of the method. If we didn’t put the hidden sequence point in front of the conditional branch the execution would continue in the old code until another sequence point is hit. Such a sequence point can be arbitrary (suppose e.g. that the else block of the if statement is deleted by an edit). The debugger only knows how to map IP of active statements in the old IL to an IP in the new IL, not arbitrary sequence points. By inserting the hidden sequence point we force the mapping to be performed at well-defined point that we can map to the new method body.
      
      The presence of the hidden sequence point then implies the need of storing the value of the if-statement condition to a long-lived local and reloading it back right after the sequence point. The store will happen before the IP is remapped and the load will happen in the new frame. The synthesized local must be allocated the same slot in the new frame so that its value is transferred from the old frame to the new frame.
      
      Fixes bug 927151: Edit and Continue breaks If statements while inside the conditional method.
      
      This change also includes an update to the test infrastructure to
      1) make it easier to update failing test that checks for an expected IL
      If a VerifyIL fails it synthesizes a temp file containing the unit test source and prints out a link that launches a diff tool (using ROSLYN_DIFFTOOL environment variable).
      2) to be able to directly test correspondence of sequence points to IL.
      VerifyIL has now an optional argument “sequencePoints”. When specified the printed IL will contain marks that designate presence of sequence points at IL offsets. “-“ for regular sequence point, “~” for hidden sequence points.
      I have updated some tests that are supposed to validate correspondence of sequence points to IL instructions to use this new format.  (changeset 1299447)
      b0615ac8
  28. 20 6月, 2014 1 次提交
  29. 06 6月, 2014 1 次提交
  30. 23 5月, 2014 2 次提交
    • W
      Adjust Sequence Points for C# Using to align with Break Points · 5a846eab
      wochae 提交于
      The sequence point used to be on the "using" keyword while the break point spans around both "using" keyword and the expression. Here, we adjust sequence points to be aligned with break points. Also, we update unittests in a way that the markup can be used to identify a specific span which is verified. (changeset 1261135)
      5a846eab
    • T
      Stores Encoding on SourceText so that we can always calculate checksum of the... · 97862d24
      TomasMatousek 提交于
      Stores Encoding on SourceText so that we can always calculate checksum of the underlying binary data, even if the SourceText wasn’t created from a Stream.
      
      Adds WithRootAndOptions and WithFilePath methods to SyntaxTree and implements them for all subclasses. I decided to merge WithRoot and WithOptions to a single method WithRootAndOptions since setting one without the other doesn't make much sense (the options should correspond to the root node).
      
      Propagates the Encoding throughout workspaces and services.
      Refactors recoverable syntax trees so that they can implement With* methods.
      
      Allow encoding on SourceText to be unspecified (null) and report an emit diagnostic when attempting to emit debug information for a syntax tree that is backed by encoding-less source text. If user creates a syntax tree from a string they previously read from a file and then try to emit debuggable compilation with such tree the original encoding of the file might not match the default UTF8 (they might different by presence of BOM, which is quite subtle). To avoid confusion we don't set UTF8 encoding by default. Instead we report the diagnostic and the user needs to explicitly provide an encoding to the syntax tree factory method.
      
      Avoid leaking DecoderFallbackException out of EncodedStringText.Create. Throw InvalidDataException instead to reduce the amount of exceptions that the caller needs to deal with.
      
      Also moves HasSameText extension method from Services to SourceText and optimizes the comparison for the case we the SHA1 checksums are available.
       (changeset 1260412)
      97862d24
  31. 06 5月, 2014 2 次提交
    • A
      Migrated state of “Declaration Expressions” implementation equivalent to... · 2ea2068f
      AlekseyTs 提交于
      Migrated state of “Declaration Expressions” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/b7fd08a5695e21cd4d23b8b70815c53656dab65f. (changeset 1249879)
      2ea2068f
    • V
      Implementation of conditional access operators - ?. and ?[] · 6f2e0b6d
      VSadov 提交于
       Change Description:
      
           Implementation of conditional access operators ( ?. and ?[] )
      
           The grammar roughly looks like:
      
           expr ::= | ...
                    | expr ? tail
      
           tail ::= | tailopt . id
           tail ::= | tailopt .$ id                        <---   this is NYI in this change
                    | tailopt [ expr-args ]
                    | tail ( expr-args )
      
           Note that the tail isn’t optional for invocation: there is no ?(…) operator.
      
           Interesting implementation points:
      
           == Parsing/syntax
      
           Syntax tree is right associative – it has the same topology as in the grammar. However I did not create special variants for all the kinds of syntax that could be produced by the parsing of the tail of accessors.
           I just use regular syntax nodes with exception of the topmost node that is the conditional access operator itself and the lower-leftmost node that textually starts the accessor tail.
      
           The root node looks like –
      
           ConditionalAccessExpression
           {
              ExpressionSyntax Expression;
              SyntaxToken OperatorToken;                  // always “?”
              ExpressionSyntax WhenNotNull;              // by analogy with conditional expression which uses WhenTrue
           }
      
           WhenNotNull is an ExpressionSyntax that represent the sequence of postfix operations conditionally applied to the Expression. These are regular InvocationExpressions, MemberAccesses, ElementAcesses – whatever postfix operators we have.
      
           The only special part about WhenNotNull is that the low-leftmost expression child is one of 2 special “binding” nodes – MemberBindingExpression, ElementBindingExpression.
      
           Binding expressions are entities which can start the chain of WhenNotNull . Textually they look like  -  “ .SimpleName“ ,  “[argList]” or “$Name” (when $ accessor is supported).
           Note that there is no InvocationBinding, since we do not allow () to start the chain of applications – you cannot do “a?(arg)”.
           The binding expression syntaxes are basically versions of corresponding member/element/dollar access expressions without receivers.
      
           R?.a.b(x).c
      
           Would parse as
      
               ConditionalAccess
             /         |         \
           R           ?          MemberAccess
                                       /    |   \
                             Invocation     .     c
                            /           \
                      MemberAccess       ArgList{( x )}
                     /        |    \
           MemberBinding      .      b
               |      \
               .       a
      
           The advantage of using regular syntax nodes on the right side is that semantical analysis “just works”.  Naturally, because of the topology, the API cannot ask nonsensical questions like - what is the type of subexpression “R?.a.b” ?
           Since “R?.a.b” is not a subexpression, there is no way to ask such question.
           It is however possible to interrogate member accesses – they are just regular member accesses (in both syntax and bound trees) so they naturally know their types etc…
      
           == Binding
      
           Binding of the tree above is fairly simple – I only had to add binding support for the left-lowermost binding nodes. And what comes out is really just regular access expressions with placeholder receiver.
           I cannot refer to the actual receiver since we are not evaluating it again.
      
           In terms of schema - Bound tree actually needed even fewer changes than syntax tree – the bound tree for the above expression is just a regular bound tree. It is isomorphic to the syntax.
           The only new bound nodes are the root BoundConditionalAccess and the left-lowermost placeholder receiver – BoundConditionalReceiver.
      
               BoundConditionalAccess
                /                  \
           <BoundExpr>         BoundMemberAccess {c}
                                    /
                              BoundCall {b}
                             /          \
            BoundMemberAccess {a}        List<Args>{ x }
                          /
           BoundConditionalReceiver
      
           == Dataflow
      
           Dataflow considers BoundConditionalReceiver always assigned. However the whole WhenNotNull is reachable conditionally  - i.e. assignedVariables state is forked when going into WhenNotNull.
           “receiver is a const” situation is handled trivially. That is similar to the ?? operator but somewhat inverted.
      
           == Emit
      
           There are two ways to emit this :
           - In complex cases (nullables, async, expr trees) we lower the conditional access into a ternary with consequence being rewritten as0is with just BoundConditionalReceiver replaced by a temp for the receiver value.
           - In simple case (all reference types), we do not lower the node, emit of BoundConditionalAccess dups the receiver (thus avoiding an IL temp) , checks it for null and conditionally executes the the access expression.
           BoundConditionalReceiver is handled by emit by not emitting anything since it represents receiver value and that is on the stack already.
       (changeset 1249636)
      6f2e0b6d
  32. 05 5月, 2014 1 次提交