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-9895] is_escaping_closure runtime check emits full source location in -O builds #52301

Open
swift-ci opened this issue Feb 9, 2019 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Feb 9, 2019

Previous ID SR-9895
Radar None
Original Reporter pointum (JIRA User)
Type Bug
Environment

Tested with

Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1)

and

Apple Swift version 5.0 (swiftlang-1001.0.60.3 clang-1001.0.37.8)

Target: x86_64-apple-darwin18.2.0

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

md5: fb5c7a2141981b7cdca1ce52d06c51a8

Issue Description:

Optimized (Release) builds that contain `is_escaping_closure` runtime check contain full path of a source file.

The change apparently was introduced in the following commit:

"SIL: Add an is_escaping_closure instruction"
5940796

How to test:

  • Create main.swift file with the following contents:

import AppKit; NSAnimationContext.runAnimationGroup({ _ in })

  • Compile the file with optimizations and using full path (like Xcode does during builds). E.g.:

$ swiftc -O /Users/username/Desktop/main.swift

  • Search for mentions of the file name text in the output file (main)

Expected results:

Optimized (release) build should not have full source paths

Actual results:

Optimized build contains full source path

$ strings main
v16@?0@"NSAnimationContext"8
/Users/username/Desktop/main.swift
runAnimationGroup:

Notes:

The source path is not included in the output if the `is_escaping_closure` check is not used (e.g. in -Ounchecked build or when no such closures are passed to Obj-C in the app)

Other runtime checks might have a similar issue, as I could not pinpoint relevant source changes in the commit mentioned above.

@theblixguy
Copy link
Collaborator

I think this is fixed here: #22479 cc aschwaighofer@apple.com (JIRA User)

@swift-ci
Copy link
Collaborator Author

Comment by Maxim Ananov (JIRA)

Thank you. I have tested with the latest available trunk development snapshot and it is fixed now.

Swift Development Snapshot 2019-02-14 (a)

Apple Swift version 5.0-dev (LLVM 1fb4269ad2, Clang cba11ceb9f, Swift 6159ba8)

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

No branches or pull requests

2 participants