- 12 11月, 2019 1 次提交
-
-
由 Joey Robichaud 提交于
-
- 01 11月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Remove project type from Bing URI * Add Language to DiagnosticData * Trim arguments that are too long
-
- 04 10月, 2019 1 次提交
-
-
由 Manish Vasani 提交于
Also fix violations from newly added rules.
-
- 26 9月, 2019 1 次提交
-
-
由 nnpcYvIVl 提交于
-
- 13 9月, 2019 2 次提交
-
-
由 Joey Robichaud 提交于
-
由 Joey Robichaud 提交于
-
- 23 8月, 2019 1 次提交
-
-
由 Manish Vasani 提交于
This seems to cause a noticable UI delay while the NFW gets reported. We already report the AD0001 diagnostic with exception callstack and the analysis context on which exception occurred, so user has enough information to file an actionable bug. Fixes #38180
-
- 29 6月, 2019 3 次提交
-
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
- 08 6月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Ctor refactoring * Renames * Renames * Cleanup * ProjectExternalErrorReporter ctor * Refactoring * Remove dependency on VS * Aggregation improvements * Use ordinal comparer for project names * Construct ProjectExternalErrorReporter lazily * Fix off by one * Fix issues
-
- 07 6月, 2019 2 次提交
-
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
RenameTrackingDiagnosticAnalyzer is the only remaining in-process analyzer, which is tracked by #35808. Use of IInProcessAnalyzer in new locations is not allowed.
-
- 04 6月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Cleanup style * Remove BlueSquiggleForBuildDiagnostic * TableDataSource refactoring * Remove DiagnosticData.Workspace * Fix workspace reference * Simplify GetTrackingPoints * Simplify deduplication * EqualsModuloLocation * Simplify navigate to * Specialize table item * Fix assert * Feedback * Dedup TryNavigateTo * Couple of renames
-
- 31 5月, 2019 1 次提交
-
-
由 Manish Vasani 提交于
Add new analyzer API (DiagnosticSuppressor) to allow programmatic suppression of analyzer and/or compiler non-error diagnostics Fixes #20242 and #30172 Detailed design proposal [here](https://gist.github.com/mavasani/fcac17a9581b5c54cef8a689eeec954a). Added public APIs with documentation comments: ```cs namespace Microsoft.CodeAnalysis.Diagnostics { /// <summary> /// The base type for diagnostic suppressors that can programmatically suppress analyzer and/or compiler non-error diagnostics. /// </summary> public abstract class DiagnosticSuppressor : DiagnosticAnalyzer { // Disallow suppressors from reporting diagnostics or registering analysis actions. public sealed override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics => ImmutableArray<DiagnosticDescriptor>.Empty; public sealed override void Initialize(AnalysisContext context) { } /// <summary> /// Returns a set of descriptors for the suppressions that this suppressor is capable of producing. /// </summary> public abstract ImmutableArray<SuppressionDescriptor> SupportedSuppressions { get; } /// <summary> /// Suppress analyzer and/or compiler non-error diagnostics reported for the compilation. /// This may be a subset of the full set of reported diagnostics, as an optimization for /// supporting incremental and partial analysis scenarios. /// A diagnostic is considered suppressible by a DiagnosticSuppressor if *all* of the following conditions are met: /// 1. Diagnostic is not already suppressed in source via pragma/suppress message attribute. /// 2. Diagnostic's <see cref="Diagnostic.DefaultSeverity"/> is not <see cref="DiagnosticSeverity.Error"/>. /// 3. Diagnostic is not tagged with <see cref="WellKnownDiagnosticTags.NotConfigurable"/> custom tag. /// </summary> public abstract void ReportSuppressions(SuppressionAnalysisContext context); } /// <summary> /// Provides a description about a programmatic suppression of a <see cref="Diagnostic"/> by a <see cref="DiagnosticSuppressor"/>. /// </summary> public sealed class SuppressionDescriptor : IEquatable<SuppressionDescriptor> { /// <summary> /// An unique identifier for the suppression. /// </summary> public string Id { get; } /// <summary> /// Identifier of the suppressed diagnostic, i.e. <see cref="Diagnostic.Id"/>. /// </summary> public string SuppressedDiagnosticId { get; } /// <summary> /// A localizable description about the suppression. /// </summary> public LocalizableString Description { get; } } /// <summary> /// Context for suppressing analyzer and/or compiler non-error diagnostics reported for the compilation. /// </summary> public struct SuppressionAnalysisContext { /// <summary> /// Suppressible analyzer and/or compiler non-error diagnostics reported for the compilation. /// This may be a subset of the full set of reported diagnostics, as an optimization for /// supporting incremental and partial analysis scenarios. /// A diagnostic is considered suppressible by a DiagnosticSuppressor if *all* of the following conditions are met: /// 1. Diagnostic is not already suppressed in source via pragma/suppress message attribute. /// 2. Diagnostic's <see cref="Diagnostic.DefaultSeverity"/> is not <see cref="DiagnosticSeverity.Error"/>. /// 3. Diagnostic is not tagged with <see cref="WellKnownDiagnosticTags.NotConfigurable"/> custom tag. /// </summary> public ImmutableArray<Diagnostic> ReportedDiagnostics { get; } /// <summary> /// Report a <see cref="Suppression"/> for a reported diagnostic. /// </summary> public void ReportSuppression(Suppression suppression); /// <summary> /// Gets a <see cref="SemanticModel"/> for the given <see cref="SyntaxTree"/>, which is shared across all analyzers. /// </summary> public SemanticModel GetSemanticModel(SyntaxTree syntaxTree); /// <summary> /// <see cref="CodeAnalysis.Compilation"/> for the context. /// </summary> public Compilation Compilation { get; } /// <summary> /// Options specified for the analysis. /// </summary> public AnalyzerOptions Options { get; } /// <summary> /// Token to check for requested cancellation of the analysis. /// </summary> public CancellationToken CancellationToken { get; } } /// <summary> /// Programmatic suppression of a <see cref="Diagnostic"/> by a <see cref="DiagnosticSuppressor"/>. /// </summary> public struct Suppression { /// <summary> /// Creates a suppression of a <see cref="Diagnostic"/> with the given <see cref="SuppressionDescriptor"/>. /// </summary> /// <param name="descriptor"> /// Descriptor for the suppression, which must be from <see cref="DiagnosticSuppressor.SupportedSuppressions"/> /// for the <see cref="DiagnosticSuppressor"/> creating this suppression. /// </param> /// <param name="suppressedDiagnostic"> /// <see cref="Diagnostic"/> to be suppressed, which must be from <see cref="SuppressionAnalysisContext.ReportedDiagnostics"/> /// for the suppression context in which this suppression is being created.</param> public static Suppression Create(SuppressionDescriptor descriptor, Diagnostic suppressedDiagnostic); /// <summary> /// Descriptor for this suppression. /// </summary> public SuppressionDescriptor Descriptor { get; } /// <summary> /// Diagnostic suppressed by this suppression. /// </summary> public Diagnostic SuppressedDiagnostic { get; } } } ``` For batch compilation, suppressors always run after all the analyzer diagnostics have been computed. For IDE partial/incremental analysis scenario, we may run the suppressors with partial diagnostics. Suppressed diagnostics from diagnostic suppressors are equivalent to source suppressed diagnostics: they show up in the error list with "Suppression State" column as "Suppressed" and are also output to errorlog as suppressed diagnostics.
-
- 16 5月, 2019 1 次提交
-
-
由 Sam Harwell 提交于
-
- 14 12月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
-
- 10 12月, 2018 1 次提交
-
-
由 dotnet-bot 提交于
-
- 06 12月, 2018 1 次提交
-
-
由 Heejae Chang 提交于
* refactor and clean up diagnostic engine code so that it can be re-used stand alone. code refactored is related to properly set up CompilationWithAnalyzer and compute and return diagnostics * made default diagnostic analyzer service to share code with VS diagnostic analyzer service on computing diagnostics. unlike VS diagnostic analyzer, the default one doesn't persist data or calculate diagnostics per a analyzer to improve per analyzer freshes nor compute and maintain per project analyzers and etc. also, this add ability to calculate semantic diagnostics for script file. * enable semantic diagnostics for script file for misc workspace. now, C#/VB script files in misc workspace will get semantic errors as well as syntax errors. any language such as F# if document is added to misc workspace with SourceCodeKind.Script, they will automatically get semantic errors as well. this PR doesn't address changes propagations for #load which was never supported for existing C#/VB script support. * addressed PR feedbacks
-
- 05 12月, 2018 1 次提交
-
-
由 Heejae Chang 提交于
-
- 04 10月, 2018 1 次提交
-
-
由 Heejae Chang 提交于
this will cache compilation end analyzer info in diagnostic service so that it can be cheap except the very first time that most likely done by solution crawler. added tests
-
- 30 5月, 2018 1 次提交
-
-
由 Sam Harwell 提交于
-
- 11 4月, 2018 1 次提交
-
-
由 Sam Harwell 提交于
Fixes #25771
-
- 21 3月, 2018 1 次提交
-
-
由 Neal Gafter 提交于
-
- 07 3月, 2018 1 次提交
-
-
由 Heejae Chang 提交于
* enable logAnalyzerExecutionTime on IDE so that we can start track analyzer perf * removed unnecessary ICodeAnalysisDiagnosticAnalyzerExecutor interface. it was added when OOP is first introduced to make sure VS.Next dll won't get loaded to VS process if OOP is not enabled. when it is enabled by default, rather than removing the interface, implementation just moved down to feature layer to reduce code churn. now, I am properly removing unnecessary abstraction. * take Executor out of test MEF composition * added IRemoteDiagnosticAnalyzerService interface * made initial version working. * added tests * add tracking for inproc only analyzers * pass in diagnostic analyzer service * added open file performance tracking as well. * added PII test * dont hash analyzerId when it is reported by internal user * added link to LOF wiki * made blame to track open files as well. * forgot to add return in if statement * reduce threshold to 100ms decide to start from lower threshold and then iterate rather than start from higher threshold * added a way to log real time perf data in local machine with explicit option which can be used to train formula later * addressed ivan's feedbacks * renamed to ExpensiveAnalyzerInfo * addressed PR feedbacks * more renames * addressed PR feedbacks. renamed as much as I can find. * listener can be null in unit test * addressed PR feedbacks
-
- 19 12月, 2017 1 次提交
-
-
由 Heejae Chang 提交于
fixed issue where same analyzer reference is installed in both vsix and nuget. deduplication in inproc analyzer manager wasn't present in OOP case. (#23772) this doesn't address our workitem to merge those two. that work is a separate work item. this just follow what we currently do in proc.
-
- 12 12月, 2017 1 次提交
-
-
由 Sam Harwell 提交于
-
- 23 8月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 29 6月, 2017 2 次提交
-
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
- 23 5月, 2017 1 次提交
-
-
由 Heejae Chang 提交于
-
- 05 5月, 2017 1 次提交
-
-
由 Heejae Chang 提交于
exposing workspace directly cause people to depends on data/service analyzer is not supposed to depend on, also, it sometime access mutable data instead of snapshot of it which analyzer is not supposed to use. this cut the connection, and expose specific info analyzer is allowed to use in IDE case.
-
- 08 2月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 10 12月, 2016 2 次提交
-
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
diagnostics reported by open file only diagnostic analyzers such as simplify type names didn't get cleaned up properly when a file is closed. this makes sure those diagnostics only exist while the file they originated from is open.
-
- 21 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 06 11月, 2016 1 次提交
-
-
由 Jonathon Marolf 提交于
-
- 24 9月, 2016 1 次提交
-
-
由 Andy Gocke 提交于
This change drops support for .NET 4.5 and retargets to desktop 4.6 + CoreCLR. It also fixes up various analyzer warnings that were created due to the move. Fixes #12926
-
- 14 9月, 2016 1 次提交
-
-
由 Heejae Chang 提交于
added OpenFileOnly in IBuiltInAnalyzer and removed RunInProcess
-
- 10 9月, 2016 1 次提交
-
-
由 Heejae Chang 提交于
now, all builtin analyzer that is not set to only run on open files will run in OOP. any builtin analyzer that can't run in OOP should mark it as open file only. for analyzers that return only hidden severity but return different severity on runtime should use the new API to control whether it want it to run full solution or not. if set to run on full solution, it will run in OOP.
-