Skip to content

Archive attributes and runtime support for it #9432

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 10 commits into from
May 11, 2017

Conversation

eeckstein
Copy link
Contributor

Explanation: This is the second part for supporting NSKeyedArchives. It adds new attributes for classes (Doug's changes) and runtime support for it (Erik's changes).

Scope: This is a new feature

Issue: rdar://problem/32083946

Risk: Low. It only affects swift code which actually uses those attributes.

Testing: There are test case in this PR for swift CI

DougGregor and others added 10 commits May 9, 2017 12:59
…angled names.

The name mangling changed from Swift 3 to Swift 4, and may get slight
tweaks as we lock down ABI stability. Identify and warn about (in
Swift 3) or error about (in Swift 4) the cases where we don't have
obviously-stable name mangling, e.g.,

* private/fileprivate classes (whose mangled names involve the file name)
* nested classes (whose mangled names depend on their enclosing type)
* generic classes (whose mangled names involve the type arguments)
This attribute allows one to provide the "legacy" name of a class for
the purposes of archival (via NSCoding). At the moment, it is only
useful for suppressing the warnings/errors about classes with unstable
archiving names.
Generic classes don't have a single name to register, so disallow
@NSKeyedArchiveLegacy.
Currently inactive, this attribute indicates that a static initializer should be emitted to register the Objective-C metadata when the image is loaded, rather than on first use of the Objective-C metadata. Infer this attribute for NSCoding classes that won’t have static Objective-C metadata or have an @NSKeyedArchiveLegacy attributed.
…raging.

The diagnostic regarding NSCoding classes with unstable names can be
suppressed by adding @objc (the preferred solution for new code) or
@NSKeyedArchiveLegacy (for existing archives). Provide those as
Fix-Its, in that order.

(Thanks, Jordan!)
…diags.

Introduce the @NSKeyedArchiveSubclassesOnly attribute, which can be
placed on a class that conforms to NSCoding to suppress the
unstable-name diagnostics by promising to only archive
subclasses---not this class directly.
Infer @_staticInitializeObjCMetadata in those cases where we need a
static initializer to make an NSCoding-conforming class visible to the
Objective-C runtime. This does *not* include classes with one of the
@NSKeyedArchive attributes:

* @NSKeyedArchiveLegacy implies that we'll register the class
  directly, with the necessary side effect of initialize Objective-C
  metadata.
* @NSKeyedArchiveSubclassesOnly promises not to archive the class
  directly anyway.
Register class names for NSKeyedArchiver and NSKeyedUnarchiver based on the @NSKeyedArchiveLegacy and @_staticInitializeObjCMetadata class attributes.

@NSKeyedArchiveLegacy registers a class name translation.
@_staticInitializeObjCMetadata just makes sure that the metadata of a class is instantiated.

This registration code is executed as a static initializer, like a C++ global constructor.
@eeckstein
Copy link
Contributor Author

@swift-ci Please test

@eeckstein
Copy link
Contributor Author

@jrose-apple Can you please review this?

@@ -36,6 +36,7 @@
// implementations.
#define FOR_CONV_DefaultCC(...)
#define FOR_CONV_C_CC(...)
#define FOR_CONV_SwiftCC(...)
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs documentation. The other CCs are described in the nearby comments.

@jrose-apple
Copy link
Contributor

Already reviewed Doug's changes. Your changes mostly looked good to me but I'm not an IRGen person; maybe @jckarter or @rjmccall can sign off on it?

@jrose-apple
Copy link
Contributor

I am getting these warnings on Linux:

/home/jrose/public/swift/include/swift/Runtime/Metadata.h:3315:1: warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes]
SWIFT_CC(swift)
^
/home/jrose/public/swift/include/swift/Runtime/Config.h:102:22: note: expanded from macro 'SWIFT_CC'
#define SWIFT_CC(CC) SWIFT_CC_##CC
                     ^
<scratch space>:39:1: note: expanded from here
SWIFT_CC_swift
^
/home/jrose/public/swift/include/swift/Runtime/Config.h:109:39: note: expanded from macro 'SWIFT_CC_swift'
#define SWIFT_CC_swift __attribute__((swiftcall))
                                      ^

Presumably this will happen on any platform where we don't yet use the just-built Clang to build the runtime.

@jckarter jckarter self-assigned this May 10, 2017
@jckarter
Copy link
Contributor

What do we need the @_staticInitializeObjCMetadata attribute for? That seems like it could easily be abused.

@eeckstein
Copy link
Contributor Author

This attribute is automatically generated. It's for classes where we just have to make sure that it's metadata is initialized (before any unarchiving). For example non-generic subclasses of generic classes

@jckarter
Copy link
Contributor

Can we prevent people from spelling the attribute in source code?

@eeckstein
Copy link
Contributor Author

Can we prevent people from spelling the attribute in source code?

A question for @DougGregor

@jrose-apple
Copy link
Contributor

jrose-apple commented May 10, 2017

We could make it RejectByParser instead of just UserInaccessible.

@DougGregor
Copy link
Member

Yeah, that's a fine idea. I'll do the _RejectByParser thing in my PR to update the Fix-Its.

@jckarter
Copy link
Contributor

Sounds good. Runtime changes LGTM.

@DougGregor
Copy link
Member

That PR is over at #9473

@eeckstein eeckstein merged commit 04a3bef into swiftlang:swift-4.0-branch May 11, 2017
@eeckstein eeckstein deleted the archive-attrs branch May 11, 2017 01:55
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.

5 participants