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-11399] Operator returning IUO doesn't implicitly unwrap #53800

Closed
hamishknight opened this issue Aug 30, 2019 · 6 comments
Closed

[SR-11399] Operator returning IUO doesn't implicitly unwrap #53800

hamishknight opened this issue Aug 30, 2019 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@hamishknight
Copy link
Collaborator

Previous ID SR-11399
Radar rdar://problem/55042628
Original Reporter @hamishknight
Type Bug
Status Closed
Resolution Done
Environment

Swift version 5.1-dev (LLVM c5340df2d1, Swift 4fa3cef)
Target: x86_64-apple-darwin18.5.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee vukrado (JIRA)
Priority Medium

md5: 1035c13ed31b14c0199f689b983bb170

Issue Description:

The following fails to compile:

postfix operator ^^^
postfix func ^^^ (lhs: Int) -> Int! { 0 }

let x: Int = 1^^^

But arguably should, as the result of the call to ^^^ should be implicitly unwrapped, just like an equivalent function call would.

@belkadan
Copy link
Contributor

belkadan commented Sep 3, 2019

cc @xedin

@xedin
Copy link
Member

xedin commented Sep 4, 2019

@swift-ci create

@swift-ci
Copy link
Collaborator

swift-ci commented Jul 7, 2020

Comment by Vuk (JIRA)

When type checking the example in the Description

 let x: Int = 1^^^

It does not attempt a disjunction choice for an implicitly unwrapped optional because the function ref kind is Unapplied so it returns false in this method in `ConstraintSystem.cpp`. which causes it not to introduce a disjunction and causes the failure in the example.

bool OverloadChoice::isImplicitlyUnwrappedValueOrReturnValue() const {

  ...

  switch (getFunctionRefKind()) {
  case FunctionRefKind::Unapplied:
  case FunctionRefKind::Compound:
    return false;
  case FunctionRefKind::SingleApply:
  case FunctionRefKind::DoubleApply:
    return true;
  }
  llvm_unreachable("unhandled kind");
}

Here is the expression dump

(postfix_unary_expr type='$T2' location=/Users/vuk/Desktop/test.swift:5:15 range=[/Users/vuk/Desktop/test.swift:5:14 - line:5:15]
  (declref_expr type='$T0' location=/Users/vuk/Desktop/test.swift:5:15 range=[/Users/vuk/Desktop/test.swift:5:15 - line:5:15] decl=test.(file).^^^@/Users/vuk/Desktop/test.swift:3:14 function_ref=unapplied)
  (paren_expr implicit type='($T1)' location=/Users/vuk/Desktop/test.swift:5:14 range=[/Users/vuk/Desktop/test.swift:5:14 - line:5:14]
    (integer_literal_expr type='$T1' location=/Users/vuk/Desktop/test.swift:5:14 range=[/Users/vuk/Desktop/test.swift:5:14 - line:5:14] value=1 builtin_initializer=**NULL** initializer=**NULL**)))

Should the FunctionRefKind be SingleApply for the postfix operator and if so would that be an issue prior to type checking or does that get resolved/changed during type checking? In an equivalent function call the function_ref is SingleApply. Any help is greatly appreciated!

@hamishknight
Copy link
Collaborator Author

vukrado (JIRA User) Yes, the FunctionRefKind should be SingleApply for an operator call. The function ref kind gets determined in PreCheckExpression by the call to markDirectCallee. Looks like we need to be calling it for all ApplyExprs instead of just CallExprs.

@swift-ci
Copy link
Collaborator

swift-ci commented Jul 7, 2020

Comment by Vuk (JIRA)

It looks like that was it @hamishknight. Thank you! I made a PR here #32737.

@LucianoPAlmeida
Copy link
Collaborator

Resolving as PR was merged

cc @hamishknight

@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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

5 participants