Skip to content

[ModuleInterface] Propagate availability for nested types too #25662

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

Merged
merged 1 commit into from
Jun 22, 2019

Conversation

jrose-apple
Copy link
Contributor

Previously the module interface printing would scrape the AvailableAttrs from the containing decl in order to print synthesized extensions for conformances that wouldn't otherwise be printed...but that missed the case where a containing lexical scope had the availability attributes instead. Now it walks up the chain of parent DeclContexts and collects the most specific AvailableAttr for each platform.

This still isn't formally correct because it doesn't merge availability for one platform (if something inside is deprecated unconditionally but outside has an "introduced" version), but it's going to match the vast majority of code out there.

Pre-requisite for rdar://problem/50100142 and #25650.

Previously the module interface printing would scrape the
AvailableAttrs from the containing decl in order to print synthesized
extensions for conformances that wouldn't otherwise be printed...but
that missed the case where a containing lexical scope had the
availability attributes instead. Now it walks up the chain of parent
DeclContexts and collects the most specific AvailableAttr for each
platform.

This /still/ isn't formally correct because it doesn't merge
availability for one platform (if something inside is deprecated
unconditionally but outside has an "introduced" version), but it's
going to match the vast majority of code out there.

Pre-requisite for rdar://problem/50100142
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

// attributes for the same platform; formally they'd need to be merged.
bool alreadyHasMoreSpecificAttrForThisPlatform =
llvm::any_of(*cache, [nextAttr](const AvailableAttr *existingAttr) {
return existingAttr->Platform == nextAttr->Platform;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this rely on Sema diagnosing when an inner thing is available on an earlier platform than the outer thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it does. That'd be a weird thing to do, though, since it means you can use the type with one availability guard but you can't name it without a stricter one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it doesn't make sense, but I wanted to make sure we were explicitly not verifying that the existing one is earlier than the inner one here. 👍

@jrose-apple jrose-apple merged commit 15bcd23 into swiftlang:master Jun 22, 2019
@jrose-apple jrose-apple deleted the thermostat-availability branch June 22, 2019 01:00
jrose-apple added a commit to jrose-apple/swift that referenced this pull request Jun 24, 2019
…ang#25662)

Previously the module interface printing would scrape the
AvailableAttrs from the containing decl in order to print synthesized
extensions for conformances that wouldn't otherwise be printed...but
that missed the case where a containing lexical scope had the
availability attributes instead. Now it walks up the chain of parent
DeclContexts and collects the most specific AvailableAttr for each
platform.

This /still/ isn't formally correct because it doesn't merge
availability for one platform (if something inside is deprecated
unconditionally but outside has an "introduced" version), but it's
going to match the vast majority of code out there.

Pre-requisite for rdar://problem/50100142

(cherry picked from commit 15bcd23)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants