Finish off the log part of _swift_checkClassAndWarnForKeyedArchiving.

[jrose-apple]

Logs a warning the first time a problematic class is archived or unarchived. We expect people to actually fix these issues, so the performance of the warning isn't too important.

Sample output:

[timestamp] Attempting to archive Swift class '_Test.Outer.ArchivedThenUnarchived', which does not have a stable runtime name.
[timestamp] Use the 'objc' attribute to ensure that the runtime name will not change: "@objc(_TtCC5_Test5Outer22ArchivedThenUnarchived)"
[timestamp] If there are no existing archives containing this class, you can choose a unique, prefixed name instead: "@objc(ABCArchivedThenUnarchived)"

Finishes rdar://problem/32414508

[jrose-apple]

@swift-ci Please test macOS

[jrose-apple]

@swift-ci Please smoke test Linux

[itaiferber]

Overall, looks good to me! I think we can improve a bit on the messages though to make them slightly clearer to the average dev:

• @"Attempting to <archive/unarchive> <generic> Swift class with mangled name '%@'. This name is unstable and may change in the future, leading to non-decodable data."
• @"To avoid this failure, create a concrete subclass..."
• @"You can use the 'objc' attribute to ensure that the name will not change..."
• @"If there are no existing archives containing this class, you should choose a unique, prefixed name which will not change over time instead: ..."

[jrose-apple]

Will do. Letting the testing finish first to see if I need to pay special attention to the non-macOS platforms.

[itaiferber]

@jrose-apple Sounds good!

[jrose-apple]

Ah, what do you think about the demangled name? I think it has to be printed somewhere because otherwise the user won't know what class is the problem, but it doesn't fit into your version of the error message.

[itaiferber]

@jrose-apple Ah, yes. Can we suggest @"Attempting to <archive/unarchive> Swift class '%@' with mangled name '%@'. This name is unstable and may change in the future, leading to non-decodable data."?

[jrose-apple]

Is it really useful to have the (relatively long) mangled name in the first message? It's going to be printed in the fix-it anyway for non-generic classes.

Here's my latest version:

// Generic
NSLog(@"Attempting to unarchive generic Swift class '%@'. Runtime "
       "names for generic classes are unstable and may change in the "
       "future, leading to non-decodable data.", demangledString);

// Non-generic
NSLog(@"Attempting to unarchive Swift class '%@'. The runtime "
       "name for this class is unstable and may change in the future,"
       "leading to non-decodable data.", demangledString);

I definitely like including the "leading to non-decodable data" part, as well as your improved follow-up messages.

[itaiferber]

@jrose-apple I think so. This warning should be present in the cases where you didn't get the fix-it either, so otherwise, you'd never really know what the mangled name was, only that there was one. (I think especially so, most devs don't know what a "mangled name" is until they see one, and then it's pretty clear what the problem is...) No?

If we can fit the mangled name in there somewhere, I think it'll help. Otherwise, this latest iteration on messages is good!

[jrose-apple]

Hm. The compiler diagnostic specifically avoids the term "mangled", but putting it in here is probably clearer than just saying "runtime name" if it's going to show it. I guess I'll add back the "with mangled runtime name '%@'".

[jrose-apple]

Okay, how's this new version?

@swift-ci Please smoke test

[itaiferber]

LGTM — thanks, Jordan!