Missing error with WASM

[dakom]

Picking up from #249

Check out the different results from each of the following examples, each of which passes the wrong type to log_foo and should produce an error:

1. Strategy: No wasm_bindgen, pass String::from Result: correct, error is where it should be

   
   pub extern fn foo () {
   log_foo(String::from("foo"));
   }

fn log_foo(s:&str) { }

2. Strategy: No wasm_bindgen, pass `format!`
    Result: correct, error is where it should be

pub extern fn foo () { log_foo(format!("hello")); }

fn log_foo(s:&str) { }

3. Strategy: Yes wasm_bindgen, pass `String::from`
    Result: **wrong but livable** - duplicate of #249 (error is at top of file)

[wasm_bindgen]

pub extern fn foo () { log_foo(String::from("foo")); }

fn log_foo(s:&str) { }

4. Strategy: Yes wasm_bindgen, pass `format!`
    Result: **totally broken** - error does not show up in vim at all

[wasm_bindgen]

pub extern fn foo () { log_foo(format!("hello")); }

fn log_foo(s:&str) { }

[oblitum]

I think it's just a result of the code generation that's involved. Could you append the error message for each case, from simple compilation from command line?

[oblitum]

Also, on your original source, try reordering the imports, specially extern crate wasm_bindgen;, I'm suspecting it's not an issue of pointing to the top of file, but to that crate import, which happens to be the first one in your previous sample.

[chemzqm]

If you think it's bug of coc, consider paste full LSP communication, by set "rust.trace.server": "verbose"," https://github.com/neoclide/coc.nvim/wiki/Debug-language-server#using-output-channel.

I hope you understand that coc can't give error location if server don't send diagnostic to it.

[dakom]

Also, on your original source, try reordering the imports, specially extern crate wasm_bindgen;, I'm suspecting it's not an issue of pointing to the top of file, but to that crate import, which happens to be the first one in your previous sample.

From re-ordering inputs in test-case #3 I was able to make the error message appear on a use statement! :) i.e. it got sortof glued in place to something... a bit hard to explain, but I don't think there's more info I can provide for that besides maybe a video?

consider paste full LSP communication

For this (test-case #4) - do I then get the full error via :CocInfo ?

[oblitum]

No need for video I think. You can get error with :CocInfo, or as it's explained in the wiki link that @chemzqm linked.

[chemzqm]

For this (test-case #4) - do I then get the full error via :CocInfo ?

It's not full error, it's communication between coc and language server, :CocInfo would include the output, set "rust.trace.server": "verbose" to make it track all LSP communication.

[oblitum]

No need for video I think.

My intention with reordering imports was to show, maybe, that issue wasn't about pointing at top of file, but to a crate that does codegen/macro expansion, which is where your local function would be expanded in the end, but I'm not sure whether that's the usual case. It would be best to reorder, put wasm_bindgen bellow, close the editor, and reopen it to see where it points from start. In any case, @chemzqm is correct with going at messaging right away, if RLS doesn't send a given error, there's nothing coc can do. You can compare though the error output of each case from compiler, and the RLS output for each, and report an RLS bug in the end in the case RLS is at fault, but it can also simply be the compiler itself.

[chemzqm]

You can also try out your file with VSCode and rls extension, if the problem doesn't exist, it's likely to be issue of coc.

[dakom]

Wow, y'all are really on top of this!!! Thanks for all your help! I'll try to generate more info and get back to you a bit later.

[dakom]

Ah - the problem exists in VSCode too, at least the "appearing at the top of the file". Haven't tried the other yet... best would probably be to make a standalone repo so it's easily duplicated. Feel free to close this issue and I'll just comment here FYI when there's something to look at, or maybe we'll re-open if the "dissappearing error" bug doesn't happen in VSCode too

[oblitum]

@dakom nice. Maybe rust+wasm is a bit early stage for decent IDE support to work, it was released as a target platform not so long ago, it still needs a bit of maturity I think.

[dakom]

Ugh this is weird... only happening unpredictably... even in standalone project I can't seem to cause it deterministically :(

I guess I'll just hope it's some bug in language server that will work itself out! Feel free to close this

[dakom]

FYI - filed here: https://github.com/rustwasm/wasm-bindgen/issues/1097 (using VSCode for the screenshots since more people probably use that, so hopefully it'll increase the eyes on it)