-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Figure out what the stdlib should do about apple's new required reason manifest. #114186
Comments
Throwing darts:
|
+1 for this request. We're currently having to build-std ourselves for our iOS library (with a change to Thanks! |
Isn't instant using |
Apple is cracking down on device fingerprinting by apps in the app-store. This is largely a good thing for users, but might be quite problematic for us.
https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api
That is, if you call some of the APIs listed, it needs to be for one of the reasons, and you also need to include a manifest file that explains why you're doing it.
This includes a number of APIs we use in the stdlib. I am for the moment going to assume these are only problematic if the APIs are actually called rather than if they are merely present, which will mostly mean we cannot call them implicitly for no reason (e.g. I think if a user calls an API in std that maps directly to one of these, it's fine -- they'll have to justify their usage to apple. But if we implicitly call it without a way to opt out, that's a problem, and if we implicitly call it when another option exists, that's also less than ideal).
The main problems that remain are:
mach_absolute_time -- we use this in Instant, which is called internally in a ton of cases (many std::thread and std::sync apis, for example).
Ideally we'd switch
Instant
to usemach_continuous_time
, which doesn't have the same caveat. This switches behavior of Instant when sleeping (but we don't guarantee what that behavior is anyway), although doing this is blocked on Raise minimum supported Apple OS versions #104385.Alternatively, the
35F9.1
carveout also applies to our usage:So we could also issue guidance on which boilerplate people should bundle in apps that use the stdlib. This seems worse to me, since there are APIs we could use that don't require users understand the implementation details of
std::sync::Condvar::wait_timeout
or whatever.Any file IO which may be performed by things like the backtrace runtime (which users don't have a way of disabling when panics occur). @workingjubilee seems to believe we don't do any of this in the Mach-O codepath. Is there a way we can enforce this to avoid accidentally regressing it?
Anything else?
The text was updated successfully, but these errors were encountered: