- 06 3月, 2015 34 次提交
-
-
由 Tomas Matousek 提交于
-
由 Neal Gafter 提交于
Add a doc about the change in unicode version.
-
由 Neal Gafter 提交于
-
由 Paul Harrington 提交于
Remove Logger and RoslynCompilerEventSource
-
由 Ravi Chande 提交于
Move VSTelemetryLoggerTests to a closed source test project
-
由 Andrew Casey 提交于
FakeSign the concord binaries
-
由 Heejae Chang 提交于
support compilation end action in v1 diagnostic engine
-
由 Tom Meschter 提交于
Disable the UnusedDeclarationsAnalyzer by default
-
由 Andrew Casey 提交于
Run FakeSign.exe on the concord binaries that we import as IL and re-assemble ourselves. This makes it possible to load them in CI builds on Jenkins. CR: @jaredpar; @jasonmalinowski
-
由 Tom Meschter 提交于
Related to issue #1058. The analyzer reports thousands of spurious errors when running over Roslyn.sln. In order to move forward to newer builds of the toolset compilers and diagnostics, it needs to be disabled.
-
由 Charles Stoner 提交于
Expand root-level synthetic IEnumerable values without an intermediate "Results View" row Removing the intermediate "Results View" row for synthetic values allows LINQ queries to be expanded automatically in the Immediate Window.
-
由 Ravi Chande 提交于
-
由 Ravi Chande 提交于
-
由 Matt Warren 提交于
Improve Encoding support in SyntaxTrees and Documents
-
由 Charles Stoner 提交于
-
由 Heejae Chang 提交于
I went thorough v1 diagnostic engine to fully support compilation end actions. now it should properly cache and report errors to associated services when there is compilation end actions registered. but admittedly I didn't tighten it as much as I can assuming all these will change once we move to v2. but this should do its job.
-
由 Charles Stoner 提交于
-
由 Paul Harrington 提交于
-
由 Manish Vasani 提交于
Fix execution of CompilationStartActions when only analyzer options for the project change, but the underlying compilation is identical. Our current assumption for executing CompilationStartActions is that they should be executed exactly once per-compilation per-analyzer. We cache the registered nested actions for every compilation in AnalyzerManager to ensure this. However, if user just changes an additional document for the project, then the analyzer options change, but the underlying compilation is unchanged. Project change causes IDE diagnostic service to clear all cached diagnostics, but when re-computing diagnostics, we end up skipping execution of CompilationStartActions and directly move to nested compilation actions. This can be troublesome in couple of ways. First, we will have duplicate callbacks for all nested actions for the initially invoked compilation start action. Second, and event worse, if the analyzer is reading the contents of the additional documents in the start action and caching them for later use by the nested actions, all the nested actions get stale contents for the additional documents. Apparently, Tom is the first one to go through this agony as the DeclarePublicAPI analyzer that he implemented exactly does the latter. Fix is to ensure that we execute compilation start actions for every unique compilation start analysis context, i.e. {compilation, analyzer options} tuple for every analyzer. This change fixes #530
-
由 Kevin Halverson 提交于
Simplify GetEvaluationResultsAndContinue...
-
由 Charles Stoner 提交于
-
由 Charles Stoner 提交于
-
由 Tomáš Matoušek 提交于
Enable EnC for C# methods containing lambdas and closures
-
由 Kevin Halverson 提交于
I *think* this should behave the same. We can remove the range check in the lambda and just call GetEvaluationResultsAndContinue again with "index + 1". The outer if should catch the index >= numRows case and call the completionRoutine.
-
由 Manish Vasani 提交于
Address CR feedback from Heejae: Avoid unnecessary IEqualityComparer<AnalyzerAndOptions>, set concurrency level for concurrent dictionary, and add early out checks based on reference equality in added Equals overrides.
-
由 Andrew Casey 提交于
Copy ResultProvider sources, rather than binaries
-
由 Kevin Halverson 提交于
Make ExpressionCompiler and ResultProvider public...
-
由 Jared Parsons 提交于
Looks like some of the MSBuild files got checked in under Src instead of src. This corrects that. closes #1045
-
由 Brett Forsgren 提交于
fix missed or incorrect localized strings in tests
-
由 Kevin Halverson 提交于
Reflection APIs used by the dispatcher to create these classes may not be available on all platforms.
-
由 Andrew Casey 提交于
We need to produce two copies of each ResultProvider DLL, one that runs on NetFX20 and one that is Portable. We originally believed that we could create a single DLL that would work for both and so we just copied the output of each ResultProvider project and signed it with a different Authenticode certificate. Now we know that - even though the source of both versions will be the same - we need to actually recompile for Portable. As a first step, we eliminate the copying mechanism and split each ResultProvider project in two. To minimize duplication, we introduce shared projects that hold on to most of the source. The next step will be to make the two copies reference different assemblies.
-
由 Tom Meschter 提交于
Clean up Solution Explorer context menus
-
由 Andrew Casey 提交于
-
由 Dustin Campbell 提交于
Fix issue introduced by recent change that breaks web scenarios
-
- 05 3月, 2015 6 次提交
-
-
由 Tom Meschter 提交于
If the user selects a bunch of diagnostics with differing severities in Solution Explorer, right-clicks, and opens the "Set Rule Set Severity" submenu they will see a check mark next to every applicable severity. E.g., if one rule is an error and one is a warning, then both Error and Warn will be checked. The general feeling is that this will be confusing to users. Instead, only show a check mark when all the selected rules share the same severity.
-
由 Dustin Campbell 提交于
Of course, a ContainedLanguage will never be an IProjectionBuffer. So, this method always returns an empty enumerable. Instead, the cast should be against _containedLanguage.DataBuffer. #hangsheadinshame
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
Fix execution of CompilationStartActions when only analyzer options for the project change, but the underlying compilation is identical. Our current assumption for executing CompilationStartActions is that they should be executed exactly once per-compilation per-analyzer. We cache the registered nested actions for every compilation in AnalyzerManager to ensure this. However, if user just changes an additional document for the project, then the analyzer options change, but the underlying compilation is unchanged. Project change causes IDE diagnostic service to clear all cached diagnostics, but when re-computing diagnostics, we end up skipping execution of CompilationStartActions and directly move to nested compilation actions. This can be troublesome in couple of ways. First, we will have duplicate callbacks for all nested actions for the initially invoked compilation start action. Second, and event worse, if the analyzer is reading the contents of the additional documents in the start action and caching them for later use by the nested actions, all the nested actions get stale contents for the additional documents. Apparently, Tom is the first one to go through this agony as the DeclarePublicAPI analyzer that he implemented exactly does the latter. Fix is to ensure that we execute compilation start actions for every unique compilation start analysis context, i.e. {compilation, analyzer options} tuple for every analyzer.
-
由 Tomas Matousek 提交于
-
-