Conversation
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
This reverts commit efc7fd4.
kripken
left a comment
There was a problem hiding this comment.
Nice work, lgtm aside from one suggestion.
| const char* exportName, | ||
| const char** segments, | ||
| bool* segmentPassive, | ||
| const char** segmentNames, |
There was a problem hiding this comment.
Perhaps we could allow segmentNames to be NULL, and then we autogenerate the names? That's much simpler for people that don't need the names, equally as simple as before.
There was a problem hiding this comment.
Please document this change in the comment before this declaration.
|
(looks like there's a CI error too) |
It comes from code coverage, but I have no clue how this PR's changes can possibly affect the code coverage findings... |
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
|
Sorry, I didn't mean code coverage (that can be ignored), but the emscripten (JS) build: https://github.com/WebAssembly/binaryen/actions/runs/7717838024/job/21037807450?pr=6254 |
It was CodeCov in my initial submission, digging into the latest... |
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
|
@kripken the remaining failure in emscripten make no sense to me... The first one is: The second one is: This smells like an encoding issue unrelated to my changes... |
|
Looks like I am going to need help... |
This reverts commit b6bc3c8.
|
I've tried running auto_update_tests.py, but it doesn't regenerate the binaryen.js txt files, maybe because of this line: |
|
ok I managed to fix the trailing spaces issue by editing the file using GH web editor... |
|
Sorry, I should have said, |
test/binaryen.js/kitchen-sink.js
Outdated
| try { | ||
| m(); | ||
| } catch(e) { | ||
| console.trace(); |
There was a problem hiding this comment.
How helpful is this? The stack trace of the error is on e anyhow, so I'm not sure what this can add here in this catch block, but I'm not familiar with console.trace...
There was a problem hiding this comment.
in theory console.trace prints the stack trace of the last raised error, see https://developer.mozilla.org/fr/docs/Web/API/console/trace_static
but it doesn't seem to help much tbh, so I can remove it
There was a problem hiding this comment.
Let's remove it then, if there isn't a clear benefit. That stack trace should be printed anyhow by node for an uncaught exception.
That works but raises the question: what exactly are we testing ? If the generated data is checked against stored data that was actually generated by the same code, it only covers NR testing, but not correctness ? Is that the intent ? (if we move forward with the merge/TypeScript proposal, I could implement (gradually) a series of granular unit tests that would check for correctness if it makes sense) |
|
What is "NR" in this context? Yeah, these particular tests are not "functional" tests, they only compare to "golden" outputs that we trust. That is, during review we carefully verify the updates to the test expectations, and after review and landing, if a later PR would cause a change to the output then a test fails. We also need functional tests, of course. We get that in other parts of the test suite, by assertions and validation that happen in all tests, and via the fuzzer. (Are there better terms for these test types?) |
|
"NR" means non-regression.
|
|
I see, thanks! I haven't seen enough usage of those terms to internalize them I guess, but most are familiar to me (and the concepts are). We do all of the above, though performance testing of the compiler itself is not tracked (but the output is), and I guess for acceptance testing it depends how you consider Emscripten (Emscripten is a user of Binaryen and tests it heavily as part of testing itself). For unit tests we do use gtest in the |
Move from segment indexes to names. This is a breaking change to make the API more capable and consistent. An effort has been made to reduce the burden on C API users where possible (specifically, you can avoid providing names and let Binaryen make them for you, which will basically be numbers that match the indexes from before). Fixes WebAssembly#6247


Fixes #6247