Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<inheritdoc> doesn't work with fully qualified crefs #36

Open
joshua-light opened this issue Nov 27, 2023 · 1 comment
Open

<inheritdoc> doesn't work with fully qualified crefs #36

joshua-light opened this issue Nov 27, 2023 · 1 comment
Labels
bug Something isn't working roslyn Issue related to the built-in Roslyn parser
Milestone

Comments

@joshua-light
Copy link
Member

joshua-light commented Nov 27, 2023

Currently, crefs are resolved only when they're specified using short names.

E.g.

/// <inheritdoc cref="A(List{int},byte)" />
public static void A(List<int> x, int y) => ...;

public static void A(List<int> x, byte y) => ...;

We should also resolve crefs like this:

/// <inheritdoc cref="A(System.Collections.Generic.List{int},byte)" />
public static void A(List<int> x, int y) => ...;

public static void A(List<int> x, byte y) => ...;
@joshua-light joshua-light added bug Something isn't working roslyn Issue related to the built-in Roslyn parser labels Nov 27, 2023
@joshua-light joshua-light added this to the 0.0.4 milestone Nov 27, 2023
@joshua-light
Copy link
Member Author

joshua-light commented Dec 2, 2023

This feature is somewhat tricky since we don't work with symbols as this increases the generation time dramatically.

However, what we could do at least:

  • Try to search types that end with the cref value (ignoring parameters and type-parameters)
  • If any matches, then consider that it's very likely this is also a referenced type
  • Prefer types that are from the existing project vs standard ones.

This should work in 80% of the cases since we have access to the project being generated (we have all syntax trees from it) as well as System assembly which is always loaded (there could be minor mismatches, though, suppose our generator is .NET 8.0 but it generates documentation for .NET Framework 4.8 project).

We could also consider having additional optional parameters that specify paths to assembly that we could load dynamically and use as a pool of names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working roslyn Issue related to the built-in Roslyn parser
Projects
None yet
Development

No branches or pull requests

1 participant