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

Enforce union case declarations AttributeTargets #16764

Merged

Conversation

edgarfgp
Copy link
Contributor

@edgarfgp edgarfgp commented Feb 26, 2024

Description

Fixes #3112

UnionCase compiles down to a static Method so should only enforce AttributeTargets.Method SharpLab

Old Rule

  • AttributeTargets.Method ||| AttributeTargets.Property

New Rule

  • AttributeTargets.Method

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:

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

Copy link
Contributor

github-actions bot commented Feb 26, 2024

❗ 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
LanguageFeatures.fsi docs/release-notes/.Language/preview.md

@edgarfgp edgarfgp changed the title Enforce union-cases AttributeTargets Enforce union case declarations AttributeTargets Feb 26, 2024
@edgarfgp edgarfgp marked this pull request as ready for review February 27, 2024 05:53
@edgarfgp edgarfgp requested a review from a team as a code owner February 27, 2024 05:53
@edgarfgp
Copy link
Contributor Author

This is ready

Copy link
Member

@psfinaki psfinaki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix, tests and refactoring. That's a good one.

I wonder if we should add some notes to some docs about it. This is a technically correct behavior but might seem unintuitive to F# newcomers.

@edgarfgp
Copy link
Contributor Author

Thanks for the fix, tests and refactoring. That's a good one.

I wonder if we should add some notes to some docs about it. This is a technically correct behavior but might seem unintuitive to F# newcomers.

Im planning to submit a RFC with the AttributeTargets rules once Im done with #13526 to make it clear

@psfinaki
Copy link
Member

Awesome :)

@edgarfgp
Copy link
Contributor Author

edgarfgp commented Feb 29, 2024

This PR should merged before #16790. Thanks

@psfinaki
Copy link
Member

@dotnet/fsharp-team-msft

@vzarytovskii
Copy link
Member

UnionCase compiles down to a static Method so should only enforce AttributeTargets.Method SharpLab

Thought it's a breaking change, I think it's fine from the the "correctness" point of view, however having AttributeTargets.Method working feels weird, since DU constructors being "methods" in the IL is an implementation detail in F# (not in C#).

If something is using generated attributes, they can be "correctly" utilised in C#, but not in F#, since from F# standpoint, New* methods are nonexistent, and cases are treated as constructors, if that makes sense.

That said, I don't mind merging it as it is now, but it still feels weird to me that we allow Method and not Constructor.

@edgarfgp
Copy link
Contributor Author

edgarfgp commented Mar 1, 2024

That said, I don't mind merging it as it is now, but it still feels weird to me that we allow Method and not Constructor.

@vzarytovskii As you know there not an actual spec yet for this, so if Constructor make sense from the F# perspective we can add it

@vzarytovskii vzarytovskii merged commit 111a1f8 into dotnet:main Mar 1, 2024
31 checks passed
@edgarfgp edgarfgp deleted the enforce-attribute-targets-on-union-case-decl branch March 2, 2024 13:02
psfinaki pushed a commit that referenced this pull request Mar 4, 2024
* Real accessibility (#15484)

* merge

* remove unused binding

* temp

* temp

* temp

* temp

* temp

* temp

* fantomas

* temp

* temp

* quotes

* temp

* realsig build and test

* tuples, staticint tests

* SerializableAttribute tests

* SeqExpressionStepping

* AsyncExpressionStepping

* misc

* AttributeTargets

* CCtorDUWithMember ListExpressionStepping

* temp

* cleanup

* fantomas

* temp

* temp

* temp

* Automated command ran: fantomas

  Co-authored-by: KevinRansom <5175830+KevinRansom@users.noreply.github.com>

* Some cleanup

* clean

* fantoms

* temp

* merge issues

* fantomas

* temp

* Update src/Compiler/TypedTree/TypedTreeBasics.fs

Co-authored-by: Tomas Grosup <tomasgrosup@microsoft.com>

* Update src/Compiler/Optimize/Optimizer.fs

Co-authored-by: Tomas Grosup <tomasgrosup@microsoft.com>

* inline

* Fix plain build.

* Update changelog

* Fixed release notes

* feedback

* remove surplus realsigs

* Update src/Compiler/TypedTree/TypedTree.fsi

Co-authored-by: Petr Pokorny <petr@innit.cz>

* Update tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputationExpressions/ComputationExpressions.fs

Co-authored-by: Petr Pokorny <petr@innit.cz>

* baselines

* baselines

* baselines

* build.sh

* restore quotes

* moar quotes

* mutable police

* fantomas

* t

* Update baselines

* Shadowing/LinqCount.fsx baseline

* Shadowing lingcount

* access.fsx

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Tomas Grosup <tomasgrosup@microsoft.com>
Co-authored-by: Vlad Zarytovskii <vzaritovsky@hotmail.com>
Co-authored-by: Petr Pokorny <petr@innit.cz>

* Fix range start of INTERP_STRING_PART (#16785)

* use the same mechanism we used to fix the range start of INTERP_STRING_END to also fix the range start of INTERP_STRING_PART

* - use a new rule for '"}" +' to catch the correct range start
- clean up work around structures introduced before and not needed anymore with this

* Revert "- use a new rule for '"}" +' to catch the correct range start"

This reverts commit 4d01cda.

* add second PR to changelog

* remove commented poc code

* Enforce union case declarations AttributeTargets (#16764)

* Enforce union-cases AttributeTargets

* release notes

* LanguageFeature.EnforceAttributeTargetsUnionCaseDeclarations

* release notes

* format code

* improve naming

* Update src/Compiler/Checking/CheckExpressions.fs

Co-authored-by: Brian Rourke Boll <brianrourkeboll@users.noreply.github.com>

* Fix merge conflict

---------

Co-authored-by: Brian Rourke Boll <brianrourkeboll@users.noreply.github.com>

* Don't consider parse warnings as errors in ComputeTcIntermediate (#16792)

* Fix seqexpression testcases (#16795)

* correct realsignature test cases for seqexpr tests

* rename typo

---------

Co-authored-by: Kevin Ransom (msft) <codecutter@hotmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Tomas Grosup <tomasgrosup@microsoft.com>
Co-authored-by: Vlad Zarytovskii <vzaritovsky@hotmail.com>
Co-authored-by: Petr Pokorny <petr@innit.cz>
Co-authored-by: dawe <dawedawe@posteo.de>
Co-authored-by: Edgar Gonzalez <edgar.gonzalez@fundourselves.com>
Co-authored-by: Brian Rourke Boll <brianrourkeboll@users.noreply.github.com>
Co-authored-by: Florian Verdonck <florian.verdonck@outlook.com>
@auduchinok
Copy link
Member

UnionCase compiles down to a static Method

This is not always the case. There's no single direct mapping between union cases and their compiled .NET representations: depending on the union and its union cases, they compile to different things (nested classes, properties, constructor methods, case test properties, nested Tags enum and so on).

For example, these union cases compile to properties, not methods:

type U =
    | A
    | B

I don't see any tests covering these cases.

Is there an RFC for this?

@edgarfgp
Copy link
Contributor Author

edgarfgp commented Mar 4, 2024

UnionCase compiles down to a static Method

This is not always the case. There's no single direct mapping between union cases and their compiled .NET representations: depending on the union and its union cases, they compile to different things (nested classes, properties, constructor methods, case test properties, nested Tags enum and so on).

For example, these union cases compile to properties, not methods:

type U =
    | A
    | B

I don't see any tests covering these cases.

Is there an RFC for this?

@auduchinok No Yet. Im going through the issues and figuring out which AttributeTargets should be enforced. Will create a RFC at some point as soon I have a clear picture of this.

This is not always the case. There's no single direct mapping between union cases and their compiled .NET representations: depending on the union and its union cases, they compile to different things (nested classes, properties, constructor methods, case test properties, nested Tags enum and so on).

I will look into this as create a PR with tests

let attrs =
// The attributes of a union case decl get attached to the generated "static factory" method
// Enforce that the union-cases can only be targeted by attributes with AttributeTargets.Method
if g.langVersion.SupportsFeature(LanguageFeature.EnforceAttributeTargetsUnionCaseDeclarations) then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following the logic from IlxGen, this should branch on arguments for the case.
Case with no data is a property.
Case with fields is a method.

There are other concerns affecting DU IL generation (structness, null as true value, number of cases), but so far I have not found any other affecting case-level attribute placement beyond what I wrote above (and what Eugene pointed out).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review. See #16807

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you find any other case. Let me know, I really want to improve this area of the compiler

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Compiler ignores AttributeUsage for Attributes attached to union cases
6 participants