<unknown>:0: error: 'init' is inaccessible due to 'private' protection level

[ivnsch]

When I upgrade Valet to 3.2.2 (happens with 3.0.1 as well), getting this:

Any ideas? I checked the initializers of the listed classes but they're are all public and I also don't understand why this is affected by upgrading Valet.

[gfontenot]

Some questions that might help narrow things down:

• What version are you upgrading from?
• If you move back down to the previous version do these errors go away?
• Are you instantiating any Valet classes inside those types?

[aasatt]

Same error here:

• What version are you upgrading from?

Fresh install of 3.2.2 on a Swift 4.2 project

• If you move back down to the previous version do these errors go away?

Did not try. Had to remove the pod to get them away

• Are you instantiating any Valet classes inside those types?

For one class yes. Valet is only imported in 1 file. I was also getting weird errors in other files that did not have valet imported. One was simply an extension of (NS)Notification and no reference to init or private existed in that file.

[dfed]

Judging from Google... this is happening to others too: Carthage/Carthage#2587

I think this may be is an issue in both @i-schuetz's and @aasatt's code, but the reporting of the issue is incorrect due to a known Swift bug: https://bugs.swift.org/browse/SR-7644

Folks who are seeing this issue: are you trying to initialize a Valet, SecureEnclaveValet or SinglePromptSecureEnclaveValet using the initializer with no parameters? Or any chance you're referencing Valet.init, SecureEnclaveValet.init or SinglePromptSecureEnclaveValet.init?

[aasatt]

I'm creating it with an id and accessibility. I'm not referencing the init explicitly - using the shorthand version (which shouldn't make a difference):

Valet(identifier: keychainId, accessibility: .afterFirstUnlock)

[dfed]

@aasatt fascinating. Okay, so I have a speculative fix #166. Any chance you can try testing against it? You can point at the branch via CocoaPods with the following in your Podfile:

pod 'Valet', :git => 'https://github.com/square/Valet.git', :branch => 'dfed--private-protection-level'

[aasatt]

Okay so changed nothing except added :branch => 'dfed--private-protection-level' and did pod install

Looks like that might have made the initializer inaccessible. I'm getting Argument passed to call that takes no arguments on that same line of code I shared above.

[dfed]

Oh!!

Yeah, okay. I should have seen this earlier: you're using an initializer that is private. Use Valet.valet(with: keychainId, accessibility: .afterFirstUnlock) to get a Valet instance.

I think the #166 fix helps make that a bit more clear since we're no longer causing the build log to be spammed with spurious errors, so I'll merge it once it gets reviewed.

[aasatt]

Ohh wow got it.

Yeah I was reusing some code from an older project and didn't realize this was changed from VAValet.init

So your branch definitely helps to keep things safe.

Confirmed that Valet.valet(with: keychainId, accessibility: .afterFirstUnlock) works fine on both master and your branch.

Thanks @dfed

[dfed]

I can reproduce this issue on master by adding the following line to the test target and trying to run tests:

let _ = Valet(with: Identifier(nonEmpty: "compilersAreHard")!, accessibility: .whenUnlocked)

Glad we have a solution! Thank you @aasatt for the prompt responses today.

[falcon283]

@dfed
I have a similar issue while refactoring an application moving some part of the app in a Framework.
I'm curious to know how you ended up to find the root case of the issue while the Build log is showing completely different files?
Thanks you in advance.

[dfed]

@falcon283: the error message was telling me something that was obviously incorrect, but the error message mentioned a private initializer, which we had (in an NSObject subclass). So I made a speculative fix to make our overridden method match the access-level of the class definition.

Basically, trust the error message, but not the location.

[falcon283]

thanks @dfed I appreciated your response.
Yep the error is quite clear. After hours and hours a collegue of mine found the right spot and we fixed. It was as expected a public struct with internal init ... but it has not been easy to spot it.
Many Thanks