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

Jump to bottom

[SR-9960] Marking setter for property of Array type as unavailable breaks subscripting #52364

Open
lilyball mannequin opened this issue Feb 20, 2019 · 4 comments
Open

[SR-9960] Marking setter for property of Array type as unavailable breaks subscripting #52364

lilyball mannequin opened this issue Feb 20, 2019 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@lilyball
Copy link
Mannequin

lilyball mannequin commented Feb 20, 2019

Previous ID SR-9960
Radar None
Original Reporter @lilyball
Type Bug
Environment

Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1)
Target: x86_64-apple-darwin18.2.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 06200a007682f91795b6d57068c70540

Issue Description:

Swift supports marking a property setter as unavailable, but unfortunately if the property is of Array type this breaks the ability to subscript the property.

Example:

class Foo {
    var bars: [String] {
        get { return [] }
        @available(*, unavailable)
        set { fatalError() }
    }

    func foo() {
        _ = bars[2]
    }
}

This fails to compile with the error

unnamed.swift:9:13: error: setter for 'bars' is unavailable
        _ = bars[2]
            ^~~~
unnamed.swift:5:9: note: setter for 'bars' has been explicitly marked unavailable here
        set { fatalError() }
        ^
@belkadan
Copy link
Contributor

@xedin, @slavapestov, @rjmccall…LValueAccessKind?

@slavapestov
Copy link
Member

I don't think this ever worked even when Sema computed LValueAccessKind. We model this as a LoadExpr of a SubscriptExpr of lvalue type, so the availability checking thinks its a call of the setter.

Fixing this correctly would require pulling the LValueAccessKind computation back into Sema though. I'm not opposed to that in principle, as long as we find a way of doing it without duplicating similar logic in SILGen (which also implies the Sema calculation has to be "correct"; in the old world, SILGen duplicated the calculation because the Sema one wasn't right in some cases IIRC).

@rjmccall
Copy link
Member

I agree that adding LValueAccessKind back to the AST is the right way of handling this.

@slavapestov
Copy link
Member

Also let's add it back either as a separate pass that builds a side table, or a reusable visitor of some kind. The old mutable approach had problems when ASTs got "re-type checked" in weird states.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@slavapestov @belkadan @rjmccall