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-6637] Deprecation warnings from Clang-imported enums with deprecated cases #49186

ole opened this issue Dec 18, 2017 · 6 comments


Copy link

ole commented Dec 18, 2017

Previous ID SR-6637
Radar rdar://problem/34579134
Original Reporter @ole
Type Bug
Status Resolved
Resolution Done

Attachment: Download


ProductName: Mac OS X
ProductVersion: 10.13.2
BuildVersion: 17C88

Xcode 9.2
Build version 9C40b

Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 8
Component/s Compiler
Labels Bug, ClangImporter
Assignee None
Priority Medium

md5: 0fdc799ed8170d90c29fb2ac52568004

is duplicated by:

  • SR-8634 Deprecation warning at declaration site in typed enum

relates to:

  • SR-8634 Deprecation warning at declaration site in typed enum

Issue Description:

When you build an iOS app in Xcode 9.0-9.2 (with Deployment Target set to iOS 11.0 or higher) and reference the LAError type from the LocalAuthentication framework in any way, you'll get the following three deprecation warnings in the build log:

<unknown>:0: warning: 'touchIDLockout' was deprecated in iOS 11.0: use LAErrorBiometryLockout
<unknown>:0: warning: 'touchIDNotEnrolled' was deprecated in iOS 11.0: use LAErrorBiometryNotEnrolled
<unknown>:0: warning: 'touchIDNotAvailable' was deprecated in iOS 11.0: use LAErrorBiometryNotAvailable

These warnings are not attached to any particular source line because I believe they are triggered by code in the Apple headers or the generated interface by the Clang importer.

The root of the problem seems to be that iOS 11 introduced new names for these three enum cases: touchIDLockout became biometryLockout, and so on. The old names are marked as deprecated, and the new cases have the same integer values as the old ones.

It looks like the Clang importer can't handle this complicated situation without emitting the deprecation warnings, and I'm wondering if there's anything we can do about it or if we have to live with it.

For more information and background research, please check out this excellent Stack Overflow answer by Martin R's, where we discussed the same problem. The answer also mentions this related swift-users thread.

I also filed Radar 36028653, which includes a minimal Xcode project to reproduce this. The same project is attached here. I decided to also file the bug here because the more I think about it, the more I've become convinced that this isn't an issue with the LocalAuthentication framework.

It looks more like a problem in the Clang Importer that isn't specific to one particular framework. I'm not sure the maintainers of the LocalAuthentication framework can do anything to get rid of these warnings.

I'm currently working on a project where we try really hard to maintain a "zero warnings" build. Having this issue is therefore quite annoying.

Copy link

belkadan commented Dec 18, 2017

The problem is that the enum has multiple enumerators with the same value, and Swift is picking the deprecated one to be the canonical one and the others to be aliases. That's not great, but I'm concerned about having the "which constant is canonical" logic take deprecation into account, because it would change from release to release.

(We know about this and want to fix it and it just keeps not rising to the top of the list.)

Copy link
Contributor Author

ole commented Dec 18, 2017

Thanks @belkadan!

Copy link

AnthonyLatsis commented Oct 12, 2018

@belkadan, is SR-8634 a duplicate of this one?

Copy link
Contributor Author

ole commented Mar 28, 2019

After upgrading to Xcode 10.2 we no longer see these warnings in our project for touchIDLockout, touchIDNotEnrolled, and touchIDNotAvailable. It seems the problem is fixed.

@belkadan Can you confirm? Does the radar say it's fixed?

Copy link

AnthonyLatsis commented Mar 28, 2019

@ole I am pretty sure this got fixed together with SR-8634, but it was too late for 4.2 so the change only made it into 5.0.
I wasn't sure back then whether it was a duplicate.

Copy link
Contributor Author

ole commented Mar 29, 2019

@AnthonyLatsis Thanks!

@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
None yet

No branches or pull requests

3 participants