-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Some unstable runtime metrics show up as stable in docs.rs #6745
Comments
So there was a response on the rust issue, it's an issue tokio side because the nested config macros apply to the inner macro not the definitions inside |
As a newcomer looking to contribute to the project, I am interested in working on this issue. I believe I can help clarify and update the documentation to accurately reflect the stability requirements for metrics that depend on both --cfg=tokio_unstable and target_has_atomic="64". Could @Darksonn please assign me this task and guide me on how I can get started with this task? Any pointers on where to look for relevant code or documentation files would be greatly appreciated. |
The relevant file is The problem seems to be that combining multiple You are very welcome to reach out to me on the Tokio discord to discuss further. |
what is the Tokio discord channel link? |
In the documentation of runtime.rs I am not able to see the Available portion where would i be able to find that @Darksonn . Could you please guide? |
The link is: https://discord.gg/tokio |
@Darksonn, |
In the tokio RuntimeMetrics docs the majority of metrics require --cfg=tokio_unstable. Howver, some also require a target architecture with 64 bit atomics. For metrics which require both of these features rustdoc only shows one of them. Linked is an example: docs.rs/tokio/latest/tokio/runtime/struct.RuntimeMetrics.html#method.spawned_tasks_count
Here it says "Available on target_has_atomic="64" only." But it should say something like "Only available with target_has_atomic="64" and tokio_unstable."
This is a replica of the issue I raised in rust doc rust-lang/rust#128563 . This is also extra misleading as number of workers has been stabilised so it's no longer the case that all metrics are unstable.
The text was updated successfully, but these errors were encountered: