SA1137/SA1316 false positive when using primary constructors
See original GitHub issueProblem
The following code block causes false warnings. (LangVersion
set to preview
)
class A(int b)
{
public int B => b;
}
How this is a problem
It is suggesting to format the code like so:
class A(int B)
{
public int B => b;
}
When using primary constructors in non-record types, they’re considered parameters/fields, and therefore use camelCase
.
The lack of indentation is clearly unintended since the same thing isn’t raised for record types, and it goes against the rule of contents in blocks having indentation in the first place.
Issue Analytics
- State:
- Created 4 months ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
False positive S1172 for constructor parameter
A false-positive is when an issue is raised unexpectedly on code that should not trigger an issue, or where the suggested action doesn't...
Read more >S3604 misunderstands primary constructors in C# - ...
Sonarlint wants to move the two member initializers = end - start + 1 and = start . This is obviously incorrect, and...
Read more >Preview Feedback: C# 12 Primary constructors #7109
Primary constructors don't create fields. They are parameters which can be captured if used beyond the lifecycle of the constructor. The method ...
Read more >C#12 class and struct Primary Constructors : r/dotnet
Personally I'm a little bummed out because my goal for a representative constructor like this is to remove the tedium of writing property ......
Read more >"Constructor 'x' is never used" false positive when ...
CPP-18806 Subclass constructor is shown as unused while it is actually used by factory method using list initialization ; CPP-19433 "Constructor is never...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Just wanted to chime in one last time to mention that this indeed has been fixed as of version 2023.2 EAP 5 with the latest toolchain preview.
Interesting, this only happens inside Rider.
This is weird, because in theory it shouldn’t have a problem since I use the newest toolchain, but I suppose it is because Rider runs on .NET Core v7.0.4 (see detailed information above)