Enforce AttributeTargets.Class and AttributeTargets.Struct

[edgarfgp]

Description

Fixes #13526

Old rule

• Classes and Struct were using AttributeTargets.Class ||| AttributeTargets.Interface ||| AttributeTargets.Delegate ||| AttributeTargets.Struct ||| AttributeTargets.Enum

New rule

• Classes use AttributeTargets.Class
• Structs use AttributeTargets.Struct

Before

open System

[<AttributeUsage(AttributeTargets.Class)>]
type CustomClassAttribute() =
    inherit Attribute()

[<AttributeUsage(AttributeTargets.Struct)>]
type CustomStructAttribute() =
    inherit Attribute()

[<CustomClass; CustomStruct>] // No Error
type Class() = class end

[<CustomClass; CustomStruct>] // No Error
type Struct(x: int) = struct end

[<CustomClass>] // No Error
[<Struct>]
type Struct2(x: int) = ...

[<CustomStruct>] // No Error
[<Class>]
type Class2() = ...

After

open System

[<AttributeUsage(AttributeTargets.Class)>]
type CustomClassAttribute() =
    inherit Attribute()

[<AttributeUsage(AttributeTargets.Struct)>]
type CustomStructAttribute() =
    inherit Attribute()

[<CustomClass; CustomStruct>] // Error as expected as you can not use AttributeTargets.Struct in a class
type Class() = class end

[<CustomClass; CustomStruct>] // Error as expected as you can not use AttributeTargets.Class in a struct
type Struct(x: int) = struct end

[<CustomClass>] // Error as expected as you can not use AttributeTargets.Class in a struct
[<Struct>]
type Struct2(x: int) = ...

[<CustomStruct>] // Error as expected as you can not use AttributeTargets.Struct in a class
[<Class>]
type Class2() = ...

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/FSharp.Core	docs/release-notes/.FSharp.Core/8.0.300.md
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.300.md
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md

[edgarfgp]

This is ready

[vzarytovskii]

This will likely break the following scenario:

[<Struct; RequireQualifiedAccess>]
type x = { y: int }
let xx = { x.y = 123 } // Works and will emit "The record label 'y' is not defined" diagnostic without "x."

Will it now throw FS842? In case if it will, we probably can't have it as an error by default, too many things may break and either a bunch of fixes will be needed to all sorts of attributes in libraries or rewrites of the underlying types.

[edgarfgp]

This will likely break the following scenario:

[<Struct; RequireQualifiedAccess>]
type x = { y: int }
let xx = { x.y = 123 } // Works and will emit "The record label 'y' is not defined" diagnostic without "x."

Will it now throw FS842? In case if it will, we probably can't have it as an error by default, too many things may break and either a bunch of fixes will be needed to all sorts of attributes in libraries or rewrites of the underlying types.

This is unaffected as this PR checks for SynTypeDefnSimpleRepr.General as opposed SynTypeDefnSimpleRepr.Record

[vzarytovskii]

This will likely break the following scenario:

[<Struct; RequireQualifiedAccess>]
type x = { y: int }
let xx = { x.y = 123 } // Works and will emit "The record label 'y' is not defined" diagnostic without "x."

Will it now throw FS842? In case if it will, we probably can't have it as an error by default, too many things may break and either a bunch of fixes will be needed to all sorts of attributes in libraries or rewrites of the underlying types.

This is unaffected as this PR checks for SynTypeDefnSimpleRepr.General as opposed SynTypeDefnSimpleRepr.Record

Ah, good.

[vzarytovskii]

What about something like

<RequireQualifiedAccess; Struct; NoComparison>]
type ValueOrCancelled<'TResult> =
    | Value of result: 'TResult
    | Cancelled of ``exception``: OperationCanceledException

There might be a bunch of similar cases, with rqa in particular. At the very least we should extend the attribute to structs (possibly other targets).

[edgarfgp]

What about something like

<RequireQualifiedAccess; Struct; NoComparison>]
type ValueOrCancelled<'TResult> =
    | Value of result: 'TResult
    | Cancelled of ``exception``: OperationCanceledException

There might be a bunch of similar cases, with rqa in particular. At the very least we should extend the attribute to structs (possibly other targets).

This is also unaffected as this is PR does NOT check SynTypeDefnSimpleRepr.Union only checks for SynTypeDefnSimpleRepr.General

• SynTypeDefnSimpleRepr.General will cover cases like:

type MyClass() = class end

[<Class>]
type MyClass = ...

type MyStruct(x: int) = struct end

[<Struct>]
type MyStruct(x: int) = ...

So records, union and it generic counterparts still works as before.

Currently RequireQualifiedAccessAttribute is defined as follows. But I guess we can add AttributeTargets.Struct too

    [<AttributeUsage(AttributeTargets.Class, AllowMultiple=false)>]
    [<Sealed>]
    type RequireQualifiedAccessAttribute() =
        inherit Attribute()

[edgarfgp]

@auduchinok Could you have a look this one please ?

[KevinRansom]

This feels more like a bug fix than a language feature, does it really need to be tied to a language version flag?

[edgarfgp]

This feels more like a bug fix than a language feature, does it really need to be tied to a language version flag?

Agreed it is a bug, But based on previous PR's on AttributeTargets this code will stop compiling in the next version so we do not want to break existing code, that being said happy to remove the language version flag if the team is happy with

[psfinaki]

Well done and well tested. Thanks!
@T-Gro?

[T-Gro]

On top of RQA and AutoOpen, attributes where I think this change can potentially introduce breaks in user code:

• AutoSerializableAttribute
• StructuralComparisonAttribute
• StructuralEqualityAttribute
• ReflectedDefinitionAttribute (e.g. on a struct without fields and with static members)

(I am omitting all attributes working on DUs/records, as this is not the scope of this PR - but might be in the scope of future ones)

[edgarfgp]

• ReflectedDefinitionAttribute

@T-Gro Yeah I think the mentioned attributes should updated to target AttributeTargets.Struct orAttributeTargets.Class when needed. It would be good to do that in a separate PR ?

[vzarytovskii]

TypeProviderAttribute also needs to be looked at.

[edgarfgp]

TypeProviderAttribute also needs to be looked at.

@vzarytovskii Can you create an issue with all the Attributes that needs updating. Happy to do the actual work

[vzarytovskii]

TypeProviderAttribute also needs to be looked at.

@vzarytovskii Can you create an issue with all the Attributes that needs updating. Happy to do the actual work

I will update them as part of this PR, so potentially breaking change won't accidentally leak into merge/release.

[vzarytovskii]

TypeProviderAttribute also needs to be looked at.

@vzarytovskii Can you create an issue with all the Attributes that needs updating. Happy to do the actual work

I will update them as part of this PR, so potentially breaking change won't accidentally leak into merge/release.

Done

[vzarytovskii]

Nice finding @edgarfgp . See the other comment - I would rather go by extending RQA and AutoOpen to also cover structs, instead of banning it.

This is done

[edgarfgp]

Thanks @vzarytovskii You rock 🎸

[vzarytovskii]

@T-Gro can you re-review pls?

[T-Gro]

Looks good now, thanks for incorporating the changes needed.

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[edgarfgp]

I guess this PR is taking all merge conflicts today haha

[edgarfgp]

Can we have this now in ?