Comments (15)
Is this difference expected?
It's not desired, but it's a situation we know happens. We are working on a solution in dotnet/sdk#41791.
from roslyn.
This behavior is by design. We are working (#73843) to add an option where the :warning
suffix on dotnet_style_prefer_collection_expression
is ignored in favor of using the value from dotnet_diagnostic.IDE0305.severity
, but this option will not apply to individual rules (you either get the :warning
suffix support on all supported code style rules, or you do not get it at all).
I would recommend filing a bug report specifically for the dotnet_style_prefer_collection_expression
if its current configuration is problematic.
from roslyn.
@cremor Thank you very much for taking the time to file this issue with the full detail. It would have taken me a very long time to otherwise unravel this slightly different situation from the others that have been reported recently.
I'm going to keep it in its current form so we can continue to point to it in the future as the reason why code style settings should in general apply to only one diagnostic. The new issue would focus on dotnet_style_prefer_collection_expression
specifically and its impact on multiple diagnostic IDs.
from roslyn.
@sharwell I'm not sure if I understand you correctly.
Build time analysis - which was only enabled for the :severity
suffix syntax in #52991 for .NET 9 (AnalysisLevel 9) - might not support this case. Ok, that could be a known limitation (which should be documented).
But are you saying that the current behavior of the IntelliSense analysis is by design too? Should the property EnforceCodeStyleInBuild
really influence IntelliSense analysis?
from roslyn.
@cremor I don't think I understand the question. I was reviewing this issue for the limited case where EnforceCodeStyleInBuild is set to true (step 4 in the initial post). Is there a separate question you have for a scenario where it is set to false?
from roslyn.
No, my question is about when it is set to true. But I'm observing the IntelliSense analysis results in the Visual Studio error list. I'm not concerned about build time analysis output (right now).
So while I have set EnforceCodeStyleInBuild
to true (for unrelated reasons), it shouldn't affect IntelliSense analysis results in my opinion.
from roslyn.
@sharwell (Again using a mention, not sure if you saw my last message.)
I have an additional question. What did you mean with this?
I would recommend filing a bug report specifically for the dotnet_style_prefer_collection_expression if its current configuration is problematic.
Did you only mean that in the context of build time analysis, or for IntelliSense analysis too?
from roslyn.
No, my question is about when it is set to true. But I'm observing the IntelliSense analysis results in the Visual Studio error list. I'm not concerned about build time analysis output (right now).
My answer above was related to what happens on build when EnforceCodeStyleInBuild
is true. If this value is causing a difference in the IDE or some other scenario, I would need to see a description of scenario A and the behavior in scenario A, and a description of scenario B and the behavior in scenario B. At that point we can figure out why the behavior changes.
The EnforceCodeStyleInBuild
setting should only impact IntelliSense behavior for the purpose of making the IDE behavior be the same as the compile-time behavior. Sometimes when this option is false, the IDE does things that the build would not do.
Did you only mean that in the context of build time analysis, or for IntelliSense analysis too?
I'm not aware of a case where it would make a difference here.
from roslyn.
If this value is causing a difference in the IDE or some other scenario, I would need to see a description of scenario A and the behavior in scenario A, and a description of scenario B and the behavior in scenario B. At that point we can figure out why the behavior changes.
@sharwell The description is this issue. If I understand you correctly then scenario A is step 3 and scenario B is step 5 of my first post here.
from roslyn.
@sharwell -- Can this be assigned to you for further follow up?
from roslyn.
Going to go ahead and assign to Sam
from roslyn.
Since this was reopened, could someone please remove the "Resolution-By Design" label?
from roslyn.
@cremor I am not able to reproduce this issue with the 8.0.300 SDK. After both step 3 and step 5, only IDE0300 is displayed. I believe this issue may have been resolved in a newer version than 17.10.1 (I'm on Version 17.11.0 Preview 3.0 [35012.247.main]).
from roslyn.
@sharwell I can still reproduce the problem in VS 17.10.3 (SDK 8.0.302). But then I've tested 17.11.0 Preview 2.1 and it indeed seems to be fixed in that version. Thanks!
But I noticed another difference that I'd like to discuss (unrelated to the original issue):
When EnforceCodeStyleInBuild
is enabled, VS 17.10.3 shows both IDE0300 and IDE0305 warnings in the build log when I build the project.
But 17.11.0 Preview 2.1 doesn't show any warnings in the build log. Even if I remove the dotnet_diagnostic.IDE0305.severity = none
line from the editorconfig and/or install SDK 9.0.100-preview.5.24307.3 I still don't get any warnings in the build log.
Is this difference expected?
from roslyn.
Closed as Not Repro
from roslyn.
Related Issues (20)
- Hovering over a method gives the wrong overload
- Syntax highlight is half broken in both VS 17.10 and VS 17.11 P3
- False positive CS8618 null reference type warning when using required members and [SetsRequiredMembers] in derived class HOT 2
- C# rename default constructor argument which is used as a property HOT 1
- Replacing using System with #include <stdio.h> in Roslyn C# Syntax Tree Rewriter HOT 3
- Debug assert triggered for interpolated string convserion
- "dotnet build-server shutdown" warning for missing dll HOT 3
- Enabling latest-All analyzers hangs build
- TestCode classification breaks in LSP for lines that begin with whitespace
- See squigglies in #if'd code but Quick Actions don't work. HOT 1
- Method name style is not consistent along the code HOT 1
- EnC: Emit System.Runtime.CompilerServices.HotReloadException
- Go to definition is not consistent with C# compilation when a symbol is missing HOT 8
- Auto-indent doesn't work in inline diff mode HOT 1
- $$ in source code causes test always to fail
- Nonsense identifier expected error depending on how you edit unrelated code HOT 1
- [Automated] PRs inserted in VS build feature.debugger.main-35118.200
- [Automated] PRs inserted in VS build main-35118.130
- IDE0270 creates invalid code HOT 2
- NuGet packages need to include a README.md HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from roslyn.