1. 18 5月, 2016 1 次提交
  2. 05 3月, 2016 1 次提交
  3. 25 2月, 2016 1 次提交
  4. 23 2月, 2016 1 次提交
  5. 02 2月, 2016 1 次提交
  6. 06 1月, 2016 1 次提交
  7. 05 1月, 2016 1 次提交
  8. 16 12月, 2015 1 次提交
    • A
      PR changes · 35ab0f51
      Artur Spychaj 提交于
      Improves comments around the IsCompleteSubmission.
      Throws argument exception when the syntax is not a submission.
      Uses the Parser.CheckFeatureAvailability to check multiline strings.
      Renames the IsScriptOrInteractive to IsScript.
      Handle incomplete members such as an annotation.
      Do not show completions when inside of a directive.
      Add tests for symbol completion provider.
      35ab0f51
  9. 03 12月, 2015 1 次提交
  10. 24 11月, 2015 1 次提交
  11. 20 11月, 2015 1 次提交
  12. 16 11月, 2015 1 次提交
  13. 14 11月, 2015 1 次提交
    • A
      Add support for public sign to csc · ca61bad2
      Andy Gocke 提交于
      Sometimes called "fake sign" or "OSS sign" public signing is including
      the public key in an output assembly and setting the "signed" flag, but
      not actually signing the assembly with a private key. This is useful for
      open source projects where people want to build assemblies which are
      compatible with the released "fully signed" assemblies, but don't have
      access to the private key used to sign the assemblies. Since almost no
      consumers actually need to check if the assembly is fully signed, these
      publicly built assemblies are useable in almost every scenario that the
      fully signed one would be used in.
      
      This PR implements support only for C# -- VB will be added soon. If
      being used at the command line, the /publicsign flag can be passed to
      csc and the /keyfile flag can specify the public key. Unlike fully
      signing, a full key pair encoded in the SNK file format is not currently
      supported. When using /publicsign, just the public key must be in the
      /keyfile file.
      
      When using the API, the public key can be passed directly using the
      CryptoPublicKey CompilationOption.
      ca61bad2
  14. 30 10月, 2015 2 次提交
  15. 29 10月, 2015 1 次提交
    • T
      Fixes pathmap for the unix-root. Adds test case. · a83f63b6
      Ty Overby 提交于
      Previously, the unix root "/" would not be considered a valid
      path for pathmap to map to.  This commit fixes that, adds a
      test case, and adds diagnostics for unparsable pathmaps.
      a83f63b6
  16. 27 10月, 2015 1 次提交
  17. 17 10月, 2015 1 次提交
  18. 16 10月, 2015 1 次提交
  19. 14 10月, 2015 2 次提交
  20. 09 10月, 2015 1 次提交
  21. 07 10月, 2015 1 次提交
  22. 19 9月, 2015 1 次提交
  23. 17 9月, 2015 1 次提交
  24. 11 9月, 2015 1 次提交
    • K
      Minor SourceFileResolver fixups... · 89ce62cb
      Kevin Halverson 提交于
      - Undo some refactoring of CommonCompiler.ReadFileContent
      - Remove LoadDirectiveResolver
      - Make SourceReferenceResolver.ReadText detect encoding
      - Make SourceReferenceResolver.ReadText Dispose its Stream
      - Generate Diagnostic if source contains #load and SourceReferenceResolver
        is not specified in ParseOptions
      89ce62cb
  25. 05 9月, 2015 2 次提交
  26. 21 8月, 2015 1 次提交
  27. 24 7月, 2015 1 次提交
  28. 18 6月, 2015 1 次提交
  29. 10 6月, 2015 1 次提交
  30. 20 5月, 2015 1 次提交
  31. 16 5月, 2015 1 次提交
    • M
      Add a new command line compiler switch "/reportanalyzer" to report analyzer... · 3de55924
      Manish Vasani 提交于
      Add a new command line compiler switch "/reportanalyzer" to report analyzer execution times. Output is grouped by analyzer assemblies and is displayed in descending order of execution times.
      
      NOTE: We do not display the total build time or the ratios between build time and analyzer execution time as the the actual wall clock time for analyzer execution is likely lesser due to multithreaded analyzer execution.
      3de55924
  32. 15 5月, 2015 1 次提交
  33. 07 4月, 2015 1 次提交
  34. 18 3月, 2015 1 次提交
  35. 12 3月, 2015 1 次提交
  36. 11 3月, 2015 1 次提交
  37. 07 3月, 2015 1 次提交
    • V
      Restored requirement for struct constructors to always have formal parameters · 1a6b2f0d
      VSadov 提交于
      Fixes #1029
      
      While overall parameterless constructors in structs are valid from IL perspective, without a convenient way to declare them they were virtually nonexistent. As we performed more and more testing, we kept discovering cases where parameterless struct constructors caused inconsistent behavior in libraries or even in some versions of CLR.
      
      After reconsidering the potential issues arising from breaking long standing assumptions, we decided it was best for our users to restore the requirement on struct constructors to always have formal parameters.
      1a6b2f0d