-
Notifications
You must be signed in to change notification settings - Fork 291
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
Enable trust_return_value_nullability
#2791
Enable trust_return_value_nullability
#2791
Conversation
Skipping CI for Draft Pull Request. |
From chat on Matrix:
So basically we need to go over the API surfaces affected here and choose whether they do need |
0f84f80
to
47c1ae7
Compare
OK rebased this on #2814 and lifting draft. |
c499526
to
b3780e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sane to me, though I didn't review the nullability of all the APIs.
What's the behaviour if an API we thought was not nullable actually is? Does the Rust code panic on encountering the null? |
Hmm I was going to say yes, but apparently the answer is no? |
Could be interesting. I guess it depends how much we trust the current annotations to be correct? I think they should be too, but I haven't had to pay close attention to them before. I wouldn't be surprised if there's at least one or two that needs tweaking. It doesn't look like there's that many APIs being changed, so I'm happy to split it up and sanity-check their nullability if you'd like. Otherwise, I'd vote to just ship this and do any fixups as follow-ups. At least it's early in the development cycle. |
Several commonly used APIs currently unnecessarily return `Option<T>`, like `ostree_deployment_get_csum()`. Flip the gir flag for this to on; I think our annotations are correct.
The code here is not great, embarassing we've gone this long without docs for some of these public API functions too. I think this is right though.
Since we did a bunch of API changes due to nullability and other introspection cleanups.
- commit parents are optional - remote URLs are optional
Unfortunately, the nullability of the output value here is dependent on whether the `default_value` parameter is provided. There's no way to express this in introspection or Rust.
To pick up the latest introspection changes.
b3780e8
to
61a4a83
Compare
OK. I did a full audit and found a few more APIs that did need |
This adapts to the changes from ostreedev/ostree#2791 in particular.
Yep this made things better ostreedev/ostree-rs-ext#467 |
@@ -982,7 +982,7 @@ _ostree_repo_remote_name_is_file (const char *remote_name) | |||
* underneath that group, or @default_value if the remote exists but not the | |||
* option name. If an error is returned, @out_value will be set to %NULL. | |||
* | |||
* Returns: %TRUE on success, otherwise %FALSE with @error set | |||
* Returns: (nullable): %TRUE on success, otherwise %FALSE with @error set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can't be null as it is a gboolean
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I messed this up; PR incoming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This adapts to the changes from ostreedev/ostree#2791 in particular.
Enable
trust_return_value_nullability
Several commonly used APIs currently unnecessarily return
Option<T>
, likeostree_deployment_get_csum()
.Flip the gir flag for this to on; I think our annotations are
correct.
Add docs and fix annotations for ostree-repo-file.c
The code here is not great, embarassing we've gone this
long without docs for some of these public API functions too.
I think this is right though.