Enabling -Wclosure as part of -Wall, and using -Wno-closure to suppress those warnings totally makes sense to me, I don't know how bad it is in much bigger projects though (in terms of warning spam).
Some of the closure warnings were definitely useful, they weren't bugs, but definitely code smells which I have fixed now. The rest look like false positives to me. Ideally I would like to suppress individual false positives right in the source, but I guess the 'official' way of placing Closure hints into comments doesn't work because the C preprocessor already removes those. But this isn't important enough to justify an awkward workaround in Emscripten... I think I will keep the closure warnings actived when compiling in debug mode, but for release mode, use -Wno-closure to suppress them. Cheers! -Floh. On Monday, 17 October 2022 at 19:11:56 UTC+2 [email protected] wrote: > Without addressing that particular closure warning, I should explain why > you started seeing these warnings in 3.1.24. > > I landed a change that make closure warnings controlled via the normal > `-W` flags: https://github.com/emscripten-core/emscripten/pull/17878. > Those warnings were always there but emscripten was hiding them from you. > We still don't enable closure warnings by default (by default we still > hide them), but users who pass `-Wall` will now see them by default. > > I could land another change to make `-Wall` not enable `-Wclosure`, > depending on how many folks are impacted by this change. In the short term > you can pass `-Wno-closure` to revert the old behaviour. In the long term > we need to decide if `-Wclosure` being part of `-Wall` makes sense? Are > these kinds of warnings useful to you, or would you rather not see them at > all? > > cheers, > sam > > > On Sat, Oct 15, 2022 at 9:28 AM Floh <[email protected]> wrote: > >> I'm getting a lot of Closure warnings in my EM_JS() functions since >> updating to 3.1.24. >> >> For instance, when passing an XMLHttpRequest array buffer response to new >> Uint8Array, Closure can't figure out that this is indeed an ArrayBuffer. >> >> var u8_array = new Uint8Array(req.response); >> >> This results in a warning >> >> [JSC_TYPE_MISMATCH] actual parameter 1 of Uint8Array does not match >> formal parameter >> found : (Object|null|string) >> required: >> (Array<number>|ArrayBuffer|ArrayBufferView|SharedArrayBuffer|null|number) >> 768| var u8_array = new Uint8Array(req.response); >> ^^^^^^^^ >> >> I googled around and found out that Closure takes type hints like this: >> >> var u8_array = new Uint8Array(/** @type {!ArrayBuffer} */(req.response)); >> >> Any ideas how to best deal with this? >> >> Cheers, >> -Floh. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/b3eece1f-d8aa-433d-9a7c-c7d16a761062n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/b3eece1f-d8aa-433d-9a7c-c7d16a761062n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/5776e40c-e38d-480a-a204-eeb724738de3n%40googlegroups.com.
