You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This adds more information to ParseCallbacks which indicates the location in
the original source code at which a given item was found.
This has proven to be useful in downstream code generators in providing
diagnostics to explain why a given item can't be represented in Rust. (There
are lots of reasons why this might not be the case - autocxx has around 100
which can be found here -
https://github.com/google/autocxx/blob/d85eac76c9b3089d0d86249e857ff0e8c36b988f/engine/src/conversion/convert_error.rs#L39
- but irrespective of the specific reasons, it's useful to be able to point to
the original location when emitting diagnostics).
Should we make this a new callback or include this information within
the existing callback?
Pros of making it a new callback:
* No compatibility breakage.
Pros of including it in this existing callback:
* No need to specify and test a policy about whether such callbacks
always happen together, or may arrive individually
* Easier for recipients (including bindgen's own test suite) to
keep track of the source code location received.
* Because we add new items to the DiscoveryItem enum anyway,
we seem to have accepted it's OK to break compatibility in this
callback (for now at least).
Therefore I'm adding it as a parameter to the existing callback. If it's
deemed acceptable to break compatibility in this way, I will follow the
same thought process for some other changes too.
Part of google/autocxx#124.
0 commit comments