-
Notifications
You must be signed in to change notification settings - Fork 743
clang::Cursor should never be the null cursor #119
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
Comments
This sounds good, ideally we could try to never have a null/invalid cursor around, and we'd constrain their existence to the |
Is this change still wanted? It sounds like something that wouldn't be too difficult to do. |
I think so, yeah. |
Change a call to add_item that was passing a NullCursor. As a first step for issue #119, I modified the only call where we created a NullCursor to pass a None instead.
I did some tests by adding Since this would need a fair number of changes I wanted to confirm with you that this is the right way to go. |
I'd consider this as something important so we don't end up with garbage down the road by accident. However, I wonder if a transition to clang-rs would fix this. |
Right now we have various methods on
clang::Cursor
that returnOption
s just because (I think?) we call underlying clang functions that return null if the cursor is the "null cursor" (seeclang_getNullCursor
andclang_isNull
).It would be better if these methods did not return
Option
and always returned a value, ifclang::Cursor
was never the null cursor, and the place(s) where we first get a cursor return anOption<Cursor>
to handle the null cursor case. If we adopt these invariants, we should also assert them throughtclang::Cursor
methods.What do you think @emilio?
The text was updated successfully, but these errors were encountered: