Steps to Reproduce
Given the following code:
internal sealed class Example(TEntry entry)
where TEntry : class
where TValue : class
{
public required TEntry Entry { get; set; } = entry;
}
RCS0034 (PutTypeParameterConstraintOnItsOwnLine) is reported on the first where clause, and applying its code fix produces:
internal sealed class Example(TEntry entry) where TEntry : class
where TValue : class
{
public required TEntry Entry { get; set; } = entry;
}
Expected Behavior
No diagnostic should be reported. Each where clause is already on its own line, which is exactly what RCS0034 is supposed to enforce. The result of the fix is also internally inconsistent: it puts the first constraint inline while leaving the second on its own line.
Actual Behavior
RCS0034 fires on the first where clause and the code fix moves it to the declaration line, producing inconsistent formatting.
Conditions Required to Reproduce
The bug appears specifically when all of the following hold:
- The type has a primary constructor (
class Foo<...>(...)).
- There are two or more type parameters.
- There are two or more
where constraint clauses, each already on its own line.
- The type has no base type or interface list.
If any one of these is changed (single type parameter, single constraint, or a base/interface list is present), RCS0034 behaves correctly.
Related Issue
This looks like a regression / incomplete fix of #1347, which addressed the same analyzer for the case with an interface in the base list. The no-base-list + multiple-constraints case appears to have been missed.
Workaround
Suppressing the rule per-file or globally via .editorconfig:
dotnet_diagnostic.RCS0034.severity = none
Additional Notes
- I have reproduced this on the latest released version of Roslynator analyzers.
- Happy to provide a failing analyzer test case or open a PR if it helps.
Steps to Reproduce
Given the following code:
RCS0034 (
PutTypeParameterConstraintOnItsOwnLine) is reported on the firstwhereclause, and applying its code fix produces:Expected Behavior
No diagnostic should be reported. Each
whereclause is already on its own line, which is exactly what RCS0034 is supposed to enforce. The result of the fix is also internally inconsistent: it puts the first constraint inline while leaving the second on its own line.Actual Behavior
RCS0034 fires on the first
whereclause and the code fix moves it to the declaration line, producing inconsistent formatting.Conditions Required to Reproduce
The bug appears specifically when all of the following hold:
class Foo<...>(...)).whereconstraint clauses, each already on its own line.If any one of these is changed (single type parameter, single constraint, or a base/interface list is present), RCS0034 behaves correctly.
Related Issue
This looks like a regression / incomplete fix of #1347, which addressed the same analyzer for the case with an interface in the base list. The no-base-list + multiple-constraints case appears to have been missed.
Workaround
Suppressing the rule per-file or globally via
.editorconfig:dotnet_diagnostic.RCS0034.severity = none
Additional Notes