[WebIDL] Generate correct code when a pointer is returned from an interface method #21944
Conversation
tools/webidl_binder.py
Outdated
| var self = Module['getCache'](Module['%s'])[$0]; | ||
| if (!self.hasOwnProperty('%s')) throw 'a JSImplementation must implement all functions, you forgot %s::%s.'; | ||
| %sself['%s'](%s)%s; | ||
| }, (ptrdiff_t)this%s); | ||
| }''' % (c_return_type, func_name, dec_args, maybe_const, | ||
| basic_return, 'INT' if c_return_type not in C_FLOATS else 'DOUBLE', | ||
| basic_return, c_return_type, 'INT' if c_return_type not in C_FLOATS else 'DOUBLE', |
There was a problem hiding this comment.
We have EM_ASM_PTR now that we should probably use for pointer returns.
I wonder if use that then we don't need the above cast?
Maybe create a new em_asm_macro variable here that can hold the name of the macro to use?
There was a problem hiding this comment.
This is a 2.5 years old PR. I can investigate with your hint and perhaps offer an improved version. I know very little about the project internals, however.
There was a problem hiding this comment.
I refactored it with your suggestion, but the type cast cannot be avoided - the C++ compiler still raises an error for incompatible types. I incorporated the use of EM_ASM_PTR instead of EM_ASM_INT and extracted into a variable as you suggested.
|
I'm concerned that I'm getting test failures with the fixed code. At least one of the failures seems to be due to a configuration issue. The following unexpected line appears in the test output: Another test appears to be failing due to unmet memory management expectations. Again I have no clue what to do about that. The failures are likely caused by the newly added test allocating new objects and thus changing the memory layout. I ended up rearranging the WebIDL test code. Hopefully that fixes the test issues. The heap checks were getting thrown off, so I moved the new test before those. |
sbc100
changed the title
sbc100
changed the title
|
All tests appear to be passing, but an archive check seems to have stalled... |
| return &m_ObjectProvider; | ||
| } | ||
| private: | ||
| ObjectProvider m_ObjectProvider; |
There was a problem hiding this comment.
Does it really take this complex set of interwoven classes to reproduce this issue? i.e. do you need both a provider and a factory here?
There was a problem hiding this comment.
Unfortunately, yes. A single level of indirection does not expose the issue.
This fixes the problem reported under issue #14745. The previous two PRs were never completed:
#15651
#14795
Those developers are no longer involved with the project this issue is blocking and it fell to me to get it through to completion. I cleaned up the test code a bit from the earlier PRs as well. Please look at the previous PRs for details.