Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[ffigen] Nicer error messages when ObjC Blocks are invoked after deletion. #200

Open
liamappelbe opened this issue Nov 15, 2023 · 0 comments
Open

[ffigen] Nicer error messages when ObjC Blocks are invoked after deletion. #200

liamappelbe opened this issue Nov 15, 2023 · 0 comments
Labels
good first issue A good starting issue for contributors (issues with this label will appear in /contribute) package:ffigen

Comments

@liamappelbe
Copy link
Contributor

Currently if an ObjC block is invoked by native code after it has been deleted, we get a null assertion failure here, because block.ref.target.address is some junk value:

void _ObjCBlock_ffiVoid_CMPedometerData_NSError_closureTrampoline(
        ffi.Pointer<_ObjCBlock> block,
        ffi.Pointer<ObjCObject> arg0,
        ffi.Pointer<ObjCObject> arg1) =>
    _ObjCBlock_ffiVoid_CMPedometerData_NSError_closureRegistry[
        block.ref.target.address]!(arg0, arg1);
//                               ^ NPE here

Instead we should throw an exception with an error message explaining that this is probably caused by the block having been deleted.
HosseinYousefi added a commit that referenced this issue Nov 16, 2023
@HosseinYousefi
[jnigen] Refactor into Visitor pattern (#200)
253254d 
Introducing a top-level `Classes` class which includes all the classes we're trying to generate as yet another element, makes each step of the code generation pipeline, feel the same. For example exclusion of classes and methods are now both done via actually removing the objects instead of setting an `isIncluded` flag. 

This `Classes` object will go through a pipeline of:

1. `Excluder` – excludes the unwanted classes, the private ones and the ones specified by the user.
2. `Linker` – links up the objects together to create a graph.
3. `Renamer` – renames the classes, methods, fields, ... not to clash with other reserved names.
4. `DartGenerator` – generates and writes to files.
HosseinYousefi added a commit that referenced this issue Nov 16, 2023
@HosseinYousefi
[jnigen] Refactor into Visitor pattern (#200)
ca24df4 
Introducing a top-level `Classes` class which includes all the classes we're trying to generate as yet another element, makes each step of the code generation pipeline, feel the same. For example exclusion of classes and methods are now both done via actually removing the objects instead of setting an `isIncluded` flag. 

This `Classes` object will go through a pipeline of:

1. `Excluder` – excludes the unwanted classes, the private ones and the ones specified by the user.
2. `Linker` – links up the objects together to create a graph.
3. `Renamer` – renames the classes, methods, fields, ... not to clash with other reserved names.
4. `DartGenerator` – generates and writes to files.
@liamappelbe liamappelbe added the good first issue A good starting issue for contributors (issues with this label will appear in /contribute) label Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue A good starting issue for contributors (issues with this label will appear in /contribute) package:ffigen
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@liamappelbe