Type abbreviation mismatch extended data

[nojaf]

Description

Similar to the extended data added in #15840 I want to know the location of the types (in sig/impl) when an abbreviation is mismatched.

I later want to create a quick fix to update the signature file when necessary:

Checklist

• Test cases added

• Performance benchmarks added in case of performance changes

• Release notes entry updated:

  Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

  Release notes files:

  • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
  • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/releae-notes/.Language/preview.md
  • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

  Information about the release notes entries format can be found in the documentation.
  Example:

  • More inlines for Result module. (PR #16106)
  • Correctly handle assembly imports with public key token of 0 length. (Issue #16359, PR #16363)
    *while! (Language suggestion #1038, PR #14238)

  If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.300.md

[nojaf]

@DedSec256 would be nice if you could review this PR as well.
Tried to mimic what you did in your work.

[DedSec256]

Thanks for the PR! :)
In general, LGTM, there are just few comments

[nojaf]

Thanks for the review @DedSec256!

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[psfinaki]

Just to understand, what are the applicable scenarios here?

From my experience (don't want to generalize), type abbreviations are often used for things like type StringList = list<string> whereas here the test is about anon record alias so it took me a while to figure out that this is also technically a type abbreviation and hence the message applies.

I mean I know that it was like this before, just curious if we can be even more specific in the diagnostics here.

[nojaf]

Just to understand, what are the applicable scenarios here?

Basically any type alias:

// sigtypeFoo= X
// impltypeFoo= Y

Today, we get a diagnostic that there is a mismatch (X and Y differ). And where in the implementation file it is. What I'm after is getting a pointer to easily locate the type in the signature file.

To perform some code fix like:

I can pull this off, but this PR makes it a lot more easy to do it.

[psfinaki]

No I think this is a good move, but then I'd suggest adding more scenarios to the tests.

I mean this below is a very unprecise error, if we can improve the situation it would be awesome.

[nojaf]

I'd suggest adding more scenarios to the tests.

The body is irrelevant in this case, so I'm not sure what other scenarios you feel are lacking.