- 02 7月, 2015 1 次提交
-
-
由 Andrew Casey 提交于
This reverts commit 15443a23. Conflicts: src/Compilers/CSharp/Portable/CommandLine/CommandLineParser.cs src/Compilers/CSharp/Portable/PublicAPI.txt src/Compilers/Core/Portable/PublicAPI.txt src/Compilers/VisualBasic/Portable/CommandLine/CommandLineParser.vb Fixes #2888 Fixes #3786
-
- 09 6月, 2015 1 次提交
-
-
由 Jared Parsons 提交于
Fix the parsing of langVersion 14.0 to be 14 instead of 12. closes #3393
-
- 05 6月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 04 6月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 02 6月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 20 5月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 19 5月, 2015 1 次提交
-
-
由 Charles Stoner 提交于
-
- 16 5月, 2015 1 次提交
-
-
由 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.
-
- 09 5月, 2015 1 次提交
-
-
由 Jared Parsons 提交于
This moves the contents of the CSharp and Visual Basic Desktop Projects to the Portable counterparts. closes #2587
-
- 30 4月, 2015 1 次提交
-
-
由 AlekseyTs 提交于
Fixes #2371.
-
- 15 4月, 2015 1 次提交
-
-
由 Jared Parsons 提交于
This changes the following: - Changed the fallback encoding for EncodedStringText to Latin1 instead of code page 1252. The latter is not supported on CoreCLR so using the more general Latin1. - Change the VB compiler code base to be CoreCLR compatible as well.
-
- 14 4月, 2015 1 次提交
-
-
由 Jared Parsons 提交于
This changes the compiler APIs to no longer use RuntimeVersion.GetRuntimeDirectory to find the path to mscorlib and System.dll for the following reasons: - This API is not available in CoreFx and hence blocks our transition. - This behavior of implicitly referencing mscorlib doesn't have a logical equivalent in coreclr where there may be no reachable mscorlib on the machine (think Linux). The compiler now takes the SDK search directory as a paramater. The consmer will be responsible for feeding down the correct value to the compiler. This is the first step in resolving issue #1939 closes #1943
-
- 18 3月, 2015 1 次提交
-
-
由 mavasani 提交于
Add a new switch '/errorlog:' to VB and C# command line compilers to log all the compiler diagnostics into a log file. Add command line parsing tests and error log content validation tests.
-
- 11 3月, 2015 1 次提交
-
-
由 Jared Parsons 提交于
This is the initial run of the code formatter on the VB compiler source code. Further runs I'll expand on this to include all VB code in a future run.
-
- 06 3月, 2015 2 次提交
-
-
由 Tomas Matousek 提交于
Enable hosts to compile strong-named assemblies on all platforms by supplying public key via compilation options and also enable OSS signing with such key
-
由 Paul Harrington 提交于
-
- 03 3月, 2015 1 次提交
-
-
由 VSadov 提交于
The file locking cannot be consistently guaranteed on multiple platform, on remote files, when builds share process via compile server vs. running separately. Besides we are unable to handle sharing conflicts regardless, so at best the locking was serving only diagnostical purposes.
-
- 28 2月, 2015 1 次提交
-
-
由 Tom Meschter 提交于
VB has the same problem where a rule turned on in a rule set file will not be promoted to errors as you expect when using `/WarnAsError`. To fix that, `/WarnAsError` now explicitly promotes warnings from rule set files into errors. To accomplish this without breaking existing behavior around `/WarnAsError` and `/NoWarn`, we implement the following hierarchy of settings: 1. Specific `/NoWarn` arguments, in order 2. Specific `/WarnAsError` arguments, in order 3. General `/NoWarn` and `/WarnAsError` arguments, in order 4. Rule set file settings
-
- 15 1月, 2015 1 次提交
-
-
由 jaredpar 提交于
-
- 14 1月, 2015 3 次提交
-
-
由 AlekseyTs 提交于
Enable command line compiler to produce XML doc comment file and embed it as a manifest resource at the same time. Fixes #444. (changeset 1396823)
-
由 RoslynTeam 提交于
-
由 tmeschter 提交于
Currently, analyzers can access the additional files passed in to the compiler through the AnalyzerOptions.AdditionalStreams property, which returns an ImmutableArray<AdditionalStream>. AdditionalStream just wraps a Stream, and a path to the file. Exposing these files as Streams is problematic for the diagnostic author. We always meant for these additional files to be additional *text* files, and not binary files. As such, Stream is too general a type to represent them. This makes it harder for diagnostic authors to consume additional files. They need to handle opening the stream, supplying the correct encoding, (possibly) splitting up the lines, and handling any errors that might arise while doing so. This breaking change replaces AdditionalStream with AdditionalText in the portable part of the compiler layer. The derived types AdditionalFileStream (compiler desktop) and AdditionalDocumentStream (workspace layer) have become AdditionalTextFile and AdditionalTextDocument, respectively. The compiler layer now handles reading the additional file contents into SourceTexts, as well as any errors that result. (changeset 1396073)
-
- 09 1月, 2015 1 次提交
-
-
由 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)
-
- 07 1月, 2015 3 次提交
-
-
由 TomasMatousek 提交于
Marks CSharpKind and VBKind extension methods as Obsolete and adds equivalent extension methods Kind for both languages. Marks CSharpKind and VBKind instance methods on language specific syntax nodes Obsolete as well. (changeset 1389494)
-
由 TomasMatousek 提交于
-
由 TomasMatousek 提交于
Marks CSharpKind and VBKind extension methods as Obsolete and adds equivalent extension methods Kind for both languages. Marks CSharpKind and VBKind instance methods on language specific syntax nodes Obsolete as well. (changeset 1388816)
-
- 24 12月, 2014 1 次提交
-
-
由 manishv 提交于
Fix for bug 1094337: Remove /option switch in command line compilers and remove global options and culture on AnalyzerOptions Remove "/option" command line switch added for custom key-value pair analyzer options. There is no way to specify these options in the msbuild project file, so we will just revert the command line support and add it back once the end-to-end scenario is implemented for analyzer options. Additionally, also remove the Culture passed into the analyzer options. Diagnostic analyzer authors need not report localized diagnostics, just localizable diagnostics, which can be localized for any given culture by the analyzer host (IDE/command line compiler). (changeset 1384781)
-
- 04 12月, 2014 1 次提交
-
-
由 AlekseyTs 提交于
CommandLineParser.GetCompilationAndModuleNames should report an error rather than infer an empty compilation name, which would cause an exception during compilation creation. (changeset 1378023)
-
- 11 11月, 2014 1 次提交
-
-
由 nmgafter 提交于
The principal change here is to remove the language version "experimenal." However, there are a number of places in the code where we either set the language version to experimental or check whether experimental features are enabled. Those are largely vestigal at the moment as we have no experimental features. However as soon as we add experimental features that code will once again be useful. Rather than deleting that code now, I wanted to leave it in and make it easy to find and update as features are added. So I'm adding a stubbed implementation of the API proposed for future use for enabling experimental features. After Dev14 our plan is to have experimental features enabled one-by-one rather than all under a single umbrella "experimental" flag. Since language features affect the parser, this is part of the parse options. This changeset adds a stubbed version of the proposed APIs: public class ParseOptions { /// <summary> /// Enable some experimental language features for testing. /// </summary> public ParseOptions WithFeatures(IEnumerable<KeyValuePair<string, string>> features); /// <summary> /// Returns the experimental features. /// </summary> public abstract IReadOnlyDictionary<string, string> Features { get; } } (changeset 1369555)
-
- 17 10月, 2014 1 次提交
-
-
由 angocke 提交于
***NO_CI*** (changeset 1356181)
-
- 07 10月, 2014 2 次提交
-
-
由 TomasMatousek 提交于
Implements CR feedback for EmitOptions change: rename EmitOptions.OutputName to OutputNameOverride and adds TolerateErrors and IncludePrivateMembers. (changeset 1348868)
-
由 TomasMatousek 提交于
Moves options that were previously on CompilationOptions but were not used until emit phase to EmitOptions: fileAlignment, baseAddress, highEntropyVirtualAddressSpace, subsystemVersion, runtimeMetadataVersion. They hold on values written to various PE headers. We can now easily add other similar PE flags to EmitOptions, which is a common customer request, without affecting code that works with compilation options in other layers (workspaces, project system, etc.). Removes EmitMeadataOnly method and instead adds a MetadataOnly flag to EmitOptions. Removes MetadataOnlyEmitOptions - they were not used and can now be easily added as bools to EmitOptions. Moves pdbFilePath and outputName from parameters of Emit to EmitOptions. IDE: remove tracking of options that were moved to EmitOptions, since the IDE doesn't care about options that don't affect compilation. (changeset 1348623)
-
- 06 10月, 2014 1 次提交
-
-
由 ADGreen 提交于
Abbreviates the public VB-specific types (e.g. VisualBasicSyntaxTree -> VBSyntaxTree) in accordance with the .NET Class Library Guidelines to avoid overly lengthy names and consistent with the conventions used in other APIs (e.g. VB CodeDom). (changeset 1348499)
-
- 02 10月, 2014 2 次提交
-
-
由 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)
-
由 TomasMatousek 提交于
-
- 26 9月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
AssemblyMetadata and ModuleMetadata factories should not read the content of the PE file/metadata blob. Currently the factories read the headers, Assembly and Modules tables, which might result in BadImageFormatException being thrown. This exception is not turned into a compilation diagnostic because it happens before the compilation is created. A user of the Roslyn API thus needs to handle these errors in two places (as an exception and as a diagnostics). The content reading should be deferred until the AssemblyMetadata/ModuleMetadata is queried for content. This change defers metadata/PE headers reading and decoding until the AssemblyMetadata and ModuleMetadata properties/methods are called. For metadata created from files it aims to match the usage pattern of other APIs working with FileStream. The metadata factory opens the file, which might throw IO exception, but doesn't start reading the stream until the compiler asks for it, therefore it doesn't throw BadImageFormatException. The functionality is equivalent to the user opening a FileStream and creating metadata from that stream (except for a slight complication with multi-module assemblies, which are rare). Thus the API for metadata creation are consistent among in-memory byte array, stream, and file path. (changeset 1342462)
-
- 25 9月, 2014 3 次提交
- 10 9月, 2014 1 次提交
-
-
由 nmgafter 提交于
-