Conversation
KnorpelSenf
left a comment
There was a problem hiding this comment.
I'm pretty sure it was just forgotten, but let's wait for @lovasoa to confirm
|
I guess we first need to fix CI, but that is unrelated to these changes. |
|
@lovasoa do you have any idea why CI fails? It can be reproduced locally, but I honestly have no idea why the doctest fails. It works correctly for me if I do not compile the library to Wasm, and I am scared of diving into the wasm_bindgen rabbit hole just to fix this … if you can't figure it out either, I might do it anyway |
|
I had a look, I don't know where it comes from but my opinion is that the incriminated test is stupid and can be removed altogether |
|
I love it. @willbush can you delete it yourself? We can merge right after. |
Sure. Looked into it a bit and I think it's failing because |
1d7f296 to
cc01059
Compare
|
Actually, after looking at these docs, think we can just ignore targets that contain "wasm" and it will skip this test when running WASM test. Seems better than deleting the section on incompatible variables causing panic. Seems that's what other people are doing too https://github.com/search?q=%22%60%60%60should_panic%2Cignore-%22&type=code |
`should_panic` doesn't work when running for WASM target due to its default panic strategy.
cc01059 to
c560f4c
Compare
|
Those were the most plot twists I've ever seen on a pull request meant to delete a lost print statement |
|
Thank you both ! |
I left out the best part. Someone smarter than me pointed out to me how I can formulate the problem so there's always a zero solution. So this "fix" doesn't really do anything for me afterall. 🎃🍫👻 |
In how I'm using this crate not getting a solution to the constraints is a common thing and this eprintln is showing up in console output in context where no one would know where it came from. Seems like this can just be removed? Not sure if you want to add tracing or log crate dependency just for this.