Make attribute target mismatch a warning and not an error.

[edgarfgp]

Description

To reduce the impact of the EnforceAttributeTargets feature currently in preview. we should make attribute targets mismatches a warning and not an error.

Note that the warning won't be applied to desktop tests(still remains as error).

Related: #18298

Checklist

• Test cases added
• Release notes entry updated

[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/9.0.300.md

[edgarfgp]

This is ready

[auduchinok]

@edgarfgp I wanted to chime in and to thank you for working on the attributes analysis!

What I also want to add here is maybe we should not change much because of the fundamental issues that these changes are going to face in almost any case. These attributes were initially designed with .NET metadata in mind, where you annotate things like fields, properties, or methods. This doesn't map one to one for F# entities, where you also have things like union cases, functions, or values. The old implementation tried to find good-enough correspondence between F# symbols and their compiled representations, but it had its issues, all coming from this design difference. Any tweaking of the analysis is going to highlight the same issue from different angles, while also breaking the tools/frameworks/etc relying on how it was recorded many years ago. But we can't change much here: we can't add F# symbols to the common .NET attribute and expect everyone to (correctly) take it all into account. We also can't change what things are being compiled to. Often we don't even know that from syntax! (So can't assume that F# users will annotate it properly.)

Consider a simple code sample:

let a = foo

Whether a is going to be a property or a method in the metadata, depends on the type inference! I don't know what the previous implementation assumed, but we can't say easily that it's either, neither, or both.

Another case:

type U1 =
    | A
    | B of int

type U2 = int

U1.A is compiled as a property, U1.B is a nested class and a constructor method. But we don't want to assume these things either, I guess.
And U2 doesn't even exist in the metadata at all...

Any attempt to map F# things to .NET metadata entities differently will have some flaws here, so maybe sticking to what has already been done could just be a good way to break less things.

What could in theory be done is having some F#-specific attribute that F# libraries could take into account, but then we'd lose support from the broader .NET ecosystem. Maybe we could map this attribute during the compilation somehow and generate the corresponding .NET attribute instances, but it also doesn't seem to be a viable solution. (While possible in theory, it would also have issues and would require a lot of work and careful design.) In any case that I try to come up with I end up thinking we should probably just not try to change this analysis in any fundamental way here.

[edgarfgp]

@auduchinok Thanks for the detailed reply. Regarding in specific the change on this PR converting the error into a warning. I believe it is a better compromise allowing users to ignore it and rely in a previous behaviour in any F# construct.

In regards the DU cases with fields I think we can rollback the have the previous targets but still haven an opt-in warning would be good

[auduchinok]

Regarding in specific the change on this PR converting the error into a warning

Yes, thanks @edgarfgp 🙂

I just wanted to write it somewhere where a discussion is still active (i.e. instead of choosing one of many previous PR)