-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix "can't leak crate-private type in stub.rs" #662 #684
Conversation
First attempt to fix this issue for wasm32-unknown-* targets by changing visibility of functions not to leak crate-private types.
So have you got any suggestions for testing this in CI? I'm worried that this will just break again if it's untested. |
Great question! I haven't looked at the CI setup for this project yet. I have seen commit a9ec3c, which I'm guessing adds configuration to ensure I just checked, and building for |
That sounds great! |
This configuration builds plainly for the wasm32-unknown-unknown. In contrast to the existing wasm_emscripten test, this test ensures chrono builds on the latest ubuntu without wasm-pack.
Okay. As I mentioned, I duplicated the test introduced in the previous commit for wasm32-unknown-unknown. What's interesting to me, is that the existing test, "wasm_simple", appears to test the same target, and it looks like it passed in a recent run, but it fails on my machine. |
Allow me to clarify: It fails with the three errors I was seeing (Can't leak private type...), in addition to some other errors. After applying my patch, the "can't leak private type" errors disappear, but compilation still fails. I've attached the log, in case anyone is curious. |
So there's not much point in making these changes, and the added CI check is not complete (since it doesn't find these other problems)? |
Issue #210 for actions-rs/toolchain: actions-rs/toolchain#210 Indicates that the installed toolchain is not configured to be the default toolchain for GitHub actions. The OP for that issue experienced quite a bit of trouble due to this, it seems. Add configuration to ensure that the current stable toolchain is being used.
I'm actually inclined to think there might be something else going on here. The build for
All configurations experienced the three rustc errors this corrects. Additionally, that both the If the CI fails now, we know that the CI test I added covers the problem that this PR is attempting to fix, and we can go from there :). Thank you for your patience, this ended up being a little more complicated than I originally thought! |
Thanks so much for digging into this! CI indeed fails for |
First attempt to fix this issue for wasm32-unknown-* targets by changing visibility of functions not to leak crate-private types.
This fix is a hunch based on issue #210 of actions-rs/toolchain
No problem, I'm very glad to see it worked! I re-applied the fix, and I also made the same change to the CI config for the |
This reverts commit 980a6cd. Since this commit didn't have the intended effect on the CI test, I've reverted it.
I reverted my last commit related to the CI test, since it didn't appear to do what I thought it would do. I know there's been a lot of back and forth, so here's where we're at:
|
I don't think so! If CI passes I'm happy to merge this. |
Thanks for seeing this through! |
…tope#684) First attempt to fix this issue for wasm32-unknown-* targets by changing visibility of functions not to leak crate-private types. Ensure the default toolchain is used for the wasm_unknown CI test.
First attempt to fix this issue for wasm32-unknown-* targets by
changing visibility of functions not to leak crate-private types.
Tested and it builds correctly for wasm32-unknown-unknown.
Thanks for contributing to chrono!
about adding the PR number)
we can't reintroduce it?