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.

Sign up for GitHub

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-10233] Can't initialize var with function call whose stem is the same as the var name #52633

Closed
lilyball mannequin opened this issue Mar 29, 2019 · 2 comments
Closed

[SR-10233] Can't initialize var with function call whose stem is the same as the var name #52633

lilyball mannequin opened this issue Mar 29, 2019 · 2 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 Mar 29, 2019

Previous ID SR-10233
Radar None
Original Reporter @lilyball
Type Bug
Status Resolved
Resolution Duplicate
Environment

Apple Swift version 5.0 (swiftlang-1001.0.69.5 clang-1001.0.46.3)
Target: x86_64-apple-darwin18.5.0

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

md5: 4d348d1c15acacdeb52ce89ee3d3eb26

duplicates:

  • SR-1846 "Variable used in its own initial value" error when using a function (not a variable) of the same name

Issue Description:

If I have a function foo(label:) and I try and create a var foo I can't initialize it with a call to foo(label: x). This seems to be a bug in the lint that detects referencing a variable in its own initializer, because the compiler doesn't actually treat the variable and function as ambiguous.

This fails:

func foo(label: Int) -> Int { return label + 1 }
var foo = foo(label: 42) // error: variable used within its own initial value

This works:

func foo(label: Int) -> Int { return label + 1 }
var foo = 0
foo = foo(label: 42)
@theblixguy
Copy link
Collaborator

I think we need to patch `parseExprIdentifier()` in the parser to not diagnose this. This will then result in an UnresolvedDeclRefExpr being passed up and later diagnosed as "ambiguous use of...", but we could also patch `resolveDeclRefExpr()` in the type checker to check if LHS is a variable and RHS is a func and allow that, otherwise if both LHS and RHS is a variable (which has the same name/decl) then we emit the existing diagnostics.

I have a small patch ready for this, if this is a reasonable approach. cc @rintaro

@theblixguy
Copy link
Collaborator

Here's a PR: #23695

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
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
1 participant
@theblixguy