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

[SR-10988] Suggest return when the last statement of a multi-statement function body would be a valid return value #53378

Closed
jckarter opened this issue Jun 21, 2019 · 10 comments · Fixed by #42415
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation fix-its Feature: diagnostic fix-its good first issue Good for newcomers task type checker Area → compiler: Semantic analysis

Comments

@jckarter
Copy link
Member

jckarter commented Jun 21, 2019

Previous ID SR-10988
Radar None
Original Reporter @jckarter
Type Task
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Task, DiagnosticsQoI, StarterBug
Assignee Moritz (JIRA)
Priority Medium

md5: 3aba4962728f451223c8a69024161b98

Issue Description:

Now that we allow return statements to be elided in single-expression bodies, it's easy to end up during refactoring where you end up with multiple statements, but haven't yet added the return. We could detect when the last statement in a block is an ignored expr, and the type of the expr would be a valid return value, and offer a fixit, instead of sometimes-misleading error messages:

// Currently diagnoses "has 'some' return type but no return statement", but
// it could offer to fixit `x` to `return x` instead
func foo() -> some Integer {
  let x = 0
  x
}

// Currently warns "ignored expression; insert '_ ='" and then later errors because
// of missing return, but could offer to insert 'return' instead
func bar() -> Int {
  let x = 0
  x
}

// Similarly, we could suggest returns in nested block statements too when appropriate
func bas(x: Bool) -> Int {
  if x {
    0
  } else {
    1
  }
}
@swift-ci
Copy link
Collaborator

Comment by Giancarlo Buenaflor (JIRA)

Hello, I would love to tackle this one as my first contribution if that is okay.

@jckarter
Copy link
Member Author

jckarter commented Jul 1, 2019

Sounds great. Thanks buenaflor (JIRA User)!

@MartinP7r
Copy link

Hi, I'm new here, so sorry if I'm asking about obvious things.

There seems to be no activity on this. Or is there a PR or something connected to this issue? https://github.com/apple/swift/pulls?q=SR-10988 turned up empty.

If someone could point me towards the right files I could maybe try my luck. I haven't contributed anything yet and would be searching for an opportunity to get acquainted with the code base.

@swift-ci
Copy link
Collaborator

Comment by Moritz Dietsche (JIRA)

@jckarter I just submitted #42415 to address the first example in the description. The second is already implemented. Since this is my first PR to Swift, I wanted to keep it small. If you think the third one is desirable (don't fully understand the benefits tbh), I'm happy to tackle it as my next challenge.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added fix-its Feature: diagnostic fix-its type checker Area → compiler: Semantic analysis labels Feb 21, 2023
@AnthonyLatsis
Copy link
Collaborator

The first example was fixed by #42415.

@jreference
Copy link

jreference commented May 10, 2023

protocol Integer {
}
func foo() -> some Integer {
  let x = 0
  x
}

Trying this snippet gets

<source>:4:6: error: function declares an opaque return type, but has no return statements in its body from which to infer an underlying type
func foo() -> some Integer {
     ^

@AnthonyLatsis Would it be alright if i made a patch to add in a warning did you mean to return the last expression? for this case?

EDIT: Nevermind, this is behaving correctly.

@xedin
Copy link
Member

xedin commented May 10, 2023

Hm, I think we don't because x doesn't conform to Integer? If so then yeah, the current behavior is good.

@jreference
Copy link

jreference commented May 11, 2023

Hm, I think we don't because x doesn't conform to Integer? If so then yeah, the current behavior is good.

Current behavior should be correct then, the did you mean to return the last expression? note is produced as expected when x conforms to the protocol.

protocol Integer {
}

struct Bar : Integer {

}
func foo() -> some Integer {
  let x = Bar();
  x
}

@xedin
Copy link
Member

xedin commented May 11, 2023

Alright then, I think we can close this issue!

@xedin xedin closed this as completed May 11, 2023
@AnthonyLatsis
Copy link
Collaborator

I think we can close this issue!

@xedin What about the other two examples?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation fix-its Feature: diagnostic fix-its good first issue Good for newcomers task type checker Area → compiler: Semantic analysis
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants