ILSpy

9792 Commits

54 Branches

94 Tags

91 MiB

Branch: master

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	9971c7e6df	Find the member a hand-written documentation id was aiming at Typing "M:System.Linq.Enumerable.Where" at a command line is a reasonable thing to do, and it found nothing: resolution compares the whole id string, so a form without the parameter list only ever matched a member that genuinely takes none. Spelling the signature out is no answer, because it means knowing the overload count before asking. The same goes for a generic arity - and the exact spelling, Dictionary`2, does not even survive an unquoted bash prompt, where a backtick starts command substitution. None of that makes the short form legal. Measured against Roslyn: its own DocumentationCommentId resolver accepts no abbreviation at all, and the compiler never emits one - a cref is a different grammar, which the compiler binds and rewrites into a full id, warning CS0419 and picking one member when the cref is ambiguous. A prefixed cref is copied through unvalidated, so an id in a documentation file can be anything a human typed. So the id grammar stays exact and IdStringProvider stays with it, which is what lets cref-following trust its answer. The tolerance belongs to the callers that serve people typing, and lives in DocumentationIdSearch as a ladder that loosens one thing at a time: the exact id, then the id without its parameter list, then without generic arities. Stating a detail wrongly still finds nothing; only leaving one out asks for any. A rung may match several members and all of them are returned, because which to present is the caller's decision and hiding the rest would hide that the id was ambiguous. ilspycmd shows every member of the group, headed by a comment naming the ambiguity, and accepts the shapes people actually type: no prefix, a shortened namespace, and arity written the cref or C# way. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	3 weeks ago

Author

SHA1

Message

Date

Siegfried Pammer

9971c7e6df

Find the member a hand-written documentation id was aiming at

Typing "M:System.Linq.Enumerable.Where" at a command line is a reasonable thing
to do, and it found nothing: resolution compares the whole id string, so a form
without the parameter list only ever matched a member that genuinely takes none.
Spelling the signature out is no answer, because it means knowing the overload
count before asking. The same goes for a generic arity - and the exact spelling,
Dictionary`2, does not even survive an unquoted bash prompt, where a backtick
starts command substitution.

None of that makes the short form legal. Measured against Roslyn: its own
DocumentationCommentId resolver accepts no abbreviation at all, and the compiler
never emits one - a cref is a different grammar, which the compiler binds and
rewrites into a full id, warning CS0419 and picking one member when the cref is
ambiguous. A prefixed cref is copied through unvalidated, so an id in a
documentation file can be anything a human typed.

So the id grammar stays exact and IdStringProvider stays with it, which is what
lets cref-following trust its answer. The tolerance belongs to the callers that
serve people typing, and lives in DocumentationIdSearch as a ladder that loosens
one thing at a time: the exact id, then the id without its parameter list, then
without generic arities. Stating a detail wrongly still finds nothing; only
leaving one out asks for any. A rung may match several members and all of them
are returned, because which to present is the caller's decision and hiding the
rest would hide that the id was ambiguous.

ilspycmd shows every member of the group, headed by a comment naming the
ambiguity, and accepts the shapes people actually type: no prefix, a shortened
namespace, and arity written the cref or C# way.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

3 weeks ago

1 Commits (master)