Bug 189047

Summary: Add nullablity attributes to JSValue
Product: WebKit Reporter: Keith Miller <keith_miller>
Component: New BugsAssignee: Keith Miller <keith_miller>
Status: REOPENED ---    
Severity: Normal CC: commit-queue, darin, ews-watchlist, ggaren, mark.lam, mitz, msaboff, saam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 189085, 189086    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch for landing
none
Patch for landing
none
Patch mitz: review+

Description Keith Miller 2018-08-28 07:42:16 PDT
Add nullablity attributes to JSValue
Comment 1 Keith Miller 2018-08-28 07:42:45 PDT
Created attachment 348291 [details]
Patch
Comment 2 Geoffrey Garen 2018-08-28 09:58:04 PDT
Comment on attachment 348291 [details]
Patch

r=me
Comment 3 Keith Miller 2018-08-28 10:28:54 PDT
Created attachment 348306 [details]
Patch for landing
Comment 4 Keith Miller 2018-08-28 10:32:35 PDT
Comment on attachment 348306 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=348306&action=review

> Source/JavaScriptCore/API/JSValue.h:363
> +- (void)defineProperty:(nullable JSValueProperty)property descriptor:(nullable id)descriptor;

Actually, I think this needs to be nullable only when it can be an id and non-null the rest of the time. Will fix.
Comment 5 Keith Miller 2018-08-28 10:34:04 PDT
Created attachment 348308 [details]
Patch for landing
Comment 6 WebKit Commit Bot 2018-08-28 11:11:30 PDT
Comment on attachment 348308 [details]
Patch for landing

Clearing flags on attachment: 348308

Committed r235432: <https://trac.webkit.org/changeset/235432>
Comment 7 WebKit Commit Bot 2018-08-28 11:11:32 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 Radar WebKit Bug Importer 2018-08-28 11:12:30 PDT
<rdar://problem/43805577>
Comment 9 mitz 2018-08-28 11:15:41 PDT
Normally we’d enclose an API header in NS_ASSUME_NONNULL_BEGIN-NS_ASSUME_NONNULL_END and only annotate the nullable types.
Comment 10 Keith Miller 2018-08-28 11:52:09 PDT
(In reply to mitz from comment #9)
> Normally we’d enclose an API header in
> NS_ASSUME_NONNULL_BEGIN-NS_ASSUME_NONNULL_END and only annotate the nullable
> types.

Oh, I didn't know that existed. I'll upload a new version.
Comment 11 Keith Miller 2018-08-28 12:00:16 PDT
Reopening to attach new patch.
Comment 12 Keith Miller 2018-08-28 12:00:17 PDT
Created attachment 348317 [details]
Patch
Comment 13 Keith Miller 2018-08-28 13:00:46 PDT
Committed r235436: <https://trac.webkit.org/changeset/235436>
Comment 14 Darin Adler 2018-08-28 19:53:31 PDT
Will this break compatibility for Swift programs that use these methods?
Comment 15 Darin Adler 2018-08-28 19:53:57 PDT
Will this break source code compatibility for Swift programs that use these methods?
Comment 16 Keith Miller 2018-08-28 21:40:42 PDT
(In reply to Darin Adler from comment #15)
> Will this break source code compatibility for Swift programs that use these
> methods?

No, it will just generate a warning if the users don't follow the nullability rules. At least according to https://developer.apple.com/swift/blog/?id=25.
Comment 17 Darin Adler 2018-08-28 21:42:46 PDT
(In reply to Keith Miller from comment #16)
> (In reply to Darin Adler from comment #15)
> > Will this break source code compatibility for Swift programs that use these
> > methods?
> 
> No, it will just generate a warning if the users don't follow the
> nullability rules. At least according to
> https://developer.apple.com/swift/blog/?id=25.

I read that, and it’s not what it says. In Objective-C code it just creates warnings. In Swift code, the change is different. I think it *is* a source-incompatible Swift change. But maybe one that is worth doing.
Comment 18 Keith Miller 2018-08-28 22:28:01 PDT
(In reply to Darin Adler from comment #17)
> (In reply to Keith Miller from comment #16)
> > (In reply to Darin Adler from comment #15)
> > > Will this break source code compatibility for Swift programs that use these
> > > methods?
> > 
> > No, it will just generate a warning if the users don't follow the
> > nullability rules. At least according to
> > https://developer.apple.com/swift/blog/?id=25.
> 
> I read that, and it’s not what it says. In Objective-C code it just creates
> warnings. In Swift code, the change is different. I think it *is* a
> source-incompatible Swift change. But maybe one that is worth doing.

Ah, I misread your comment. Yeah, I think it's a source-incompatible Swift change. It seems like it's an incompatible change that we are encouraged to make.
Comment 19 Keith Miller 2018-08-29 10:09:08 PDT
(In reply to Keith Miller from comment #18)
> (In reply to Darin Adler from comment #17)
> > (In reply to Keith Miller from comment #16)
> > > (In reply to Darin Adler from comment #15)
> > > > Will this break source code compatibility for Swift programs that use these
> > > > methods?
> > > 
> > > No, it will just generate a warning if the users don't follow the
> > > nullability rules. At least according to
> > > https://developer.apple.com/swift/blog/?id=25.
> > 
> > I read that, and it’s not what it says. In Objective-C code it just creates
> > warnings. In Swift code, the change is different. I think it *is* a
> > source-incompatible Swift change. But maybe one that is worth doing.
> 
> Ah, I misread your comment. Yeah, I think it's a source-incompatible Swift
> change. It seems like it's an incompatible change that we are encouraged to
> make.

Investigating further it looks like we are trying to avoid source-incompatible changes. I'm gonna revert this for now.
Comment 20 WebKit Commit Bot 2018-08-29 10:10:29 PDT
Re-opened since this is blocked by bug 189085