dotnet / dotnet/docfx

[Bug] .NET API bug with ValueTuple handling

Open
#8,695 1 comment 0 reactions 0 assignees View on GitHub
dotnet
Dominant language
C#
Stars
4.4k
Forks
890
Avg merge
2h 11m
Merged PRs (30d)
10

Description

**Describe the bug**
ValueTuple brings some unexpected behaviour for DocFX reference API generation.
DocFX does `ReferenceItem` merging, but when the ValueTuple is not default - has custom named symbol names
```csharp
[return: TupleElementNames(new string[] { "name", "value" })]
ValueTuple GetCompanionWithMostKills();
```
So instead on an unnamed ValueTuple `(string, int)` we got `string name, int item`.
This breaks two asserts
https://github.com/dotnet/docfx/blob/6b81b4866e1f205321c9b7ccdc49bb96bf3549dc/src/Microsoft.DocAsCode.Dotnet/ExtractMetadata/ReferenceItem.cs#L134
https://github.com/dotnet/docfx/blob/6b81b4866e1f205321c9b7ccdc49bb96bf3549dc/src/Microsoft.DocAsCode.Dotnet/ExtractMetadata/ReferenceItem.cs#L140
The first one breaks because there are now additional NameParts, the second breaks because for the same ValueTuple signature there can exist different name pairs (`string something_else, int something_else2`)

**To Reproduce**
Steps to reproduce the behavior:
Have a signature like
```csharp
[return: TupleElementNames(new string[] { "name", "value" })]
ValueTuple GetCompanionWithMostKills();
[return: TupleElementNames(new string[] { "name", "value2" })]
ValueTuple GetCompanionWithMostElse();
```

**Expected behavior**
I didn't check the consequences, but I assume it might fail to correctly show the custom parameter names in some cases

**Context (please complete the following information):**
- OS: Windows
- Docfx version: 2.66.2
- .NET version: .NET 7.0

- `docfx.json` config:
Not needed

- Exceptions
Not needed

- Errors and warnings
Not needed

- .NET info
Not needed

**Additional context**
Not needed

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.