Rust test failures do not block PRs

[jtdavis777]

The rust tests are not considered blocking failures for PRs. I am assuming because they used to be flaky, but I think that has been fixed.

@statxc or @RenzoMXD could one of you look into making these tests required again?

[RenzoMXD]

Hello @jtdavis777
Do you mean the tests in this PR #8965 ?

[statxc]

Hey @jtdavis777, thanks for the ping. I don't have admin access to the repo, so I'm unable to modify the branch protection rules. This would need someone with admin permissions to add the Rust test checks as required status checks under Settings > Branches > Branch protection rules.

[jtdavis777]

I think this is a bazel or ci issue, not a branch protection one, but I could be wrong

[RenzoMXD]

I also agree that #8936 did good implementation for memory allocation. I will take more time to consider better solutions.

[jtdavis777]

@wlkrm tagging you as you may have missed my comment on your pr -- merging your fix caused some rust test failures. I'd like to get a PR in soon to fix these! #8936 (comment)

[RenzoMXD]

@jtdavis777 Could you please check my PR #8972? This passes the RustTesh.sh

Summary

The strings_pool field has two types depending on the std feature:

• #[cfg(feature = "std")] → HashMap (line 146)
• #[cfg(not(feature = "std"))] → Vec (line 148)

The first constructor (line 260-263) correctly uses #[cfg] guards to match. But the second constructor new_in_with_internal_capacity at line 297 always used Vec::with_capacity(...) — which is wrong when std is enabled because the field is a HashMap.

[wlkrm]

@jtdavis777, sorry, I didn't know that the tests might fail without CI failing. I think @RenzoMXD has fixed it with his PR or should I still submit a fix? Thanks @RenzoMXD!

[jtdavis777]

@statxc I have read up on how this works and see what you are saying now. I don't have access either 😅

@wlkrm no need, #8972 should be fine once it gets sorted. Thanks!