Skip to content
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

Indicate in rustdoc that items are conditionally compiled based on Rust toolchain version #894

Open
1 of 2 tasks
Tracked by #671
joshlf opened this issue Feb 17, 2024 · 0 comments
Open
1 of 2 tasks
Tracked by #671
Labels
do-after-next-release Not blocking release, but we should do soon after release

Comments

@joshlf
Copy link
Member

joshlf commented Feb 17, 2024

Progress

@joshlf joshlf mentioned this issue Feb 17, 2024
87 tasks
@joshlf joshlf added the do-after-next-release Not blocking release, but we should do soon after release label Oct 2, 2024
joshlf added a commit that referenced this issue Oct 18, 2024
Previously, we had avoided doing this because there wasn't any way to
guarantee that we didn't make mistakes and render the wrong version for
a particular named toolchain version.

In this commit, we take the pragmatic approach of renaming the named
toolchain versions - in particular, we add a suffix which includes the
toolchain version. This is fairly error-resistant for two reasons:
- At the definition site (in `Cargo.toml`), the name appears on the same
  line as the version, so mistakes should be obvious
- At the use site (in various `.rs` files), the name appears within a
  few lines of any `#[cfg_attr(doc_cfg, doc(cfg(...)))]` attribute, so
  mistakes should similarly be obvious

Closes #894

gherrit-pr-id: I74b8e9be0e6cb6e02552d2e1f985b490a7d37afe
joshlf added a commit that referenced this issue Oct 18, 2024
Previously, we had avoided doing this because there wasn't any way to
guarantee that we didn't make mistakes and render the wrong version for
a particular named toolchain version.

In this commit, we take the pragmatic approach of renaming the named
toolchain versions - in particular, we add a suffix which includes the
toolchain version. This is fairly error-resistant for two reasons:
- At the definition site (in `Cargo.toml`), the name appears on the same
  line as the version, so mistakes should be obvious
- At the use site (in various `.rs` files), the name appears within a
  few lines of any `#[cfg_attr(doc_cfg, doc(cfg(...)))]` attribute, so
  mistakes should similarly be obvious

Release 0.8.7.

Closes #894

gherrit-pr-id: I74b8e9be0e6cb6e02552d2e1f985b490a7d37afe
joshlf added a commit that referenced this issue Oct 18, 2024
Previously, we had avoided doing this because there wasn't any way to
guarantee that we didn't make mistakes and render the wrong version for
a particular named toolchain version.

In this commit, we take the pragmatic approach of renaming the named
toolchain versions - in particular, we add a suffix which includes the
toolchain version. This is fairly error-resistant for two reasons:
- At the definition site (in `Cargo.toml`), the name appears on the same
  line as the version, so mistakes should be obvious
- At the use site (in various `.rs` files), the name appears within a
  few lines of any `#[cfg_attr(doc_cfg, doc(cfg(...)))]` attribute, so
  mistakes should similarly be obvious

Release 0.8.7.

Closes #894

gherrit-pr-id: I74b8e9be0e6cb6e02552d2e1f985b490a7d37afe
github-merge-queue bot pushed a commit that referenced this issue Oct 21, 2024
Previously, we had avoided doing this because there wasn't any way to
guarantee that we didn't make mistakes and render the wrong version for
a particular named toolchain version.

In this commit, we take the pragmatic approach of renaming the named
toolchain versions - in particular, we add a suffix which includes the
toolchain version. This is fairly error-resistant for two reasons:
- At the definition site (in `Cargo.toml`), the name appears on the same
  line as the version, so mistakes should be obvious
- At the use site (in various `.rs` files), the name appears within a
  few lines of any `#[cfg_attr(doc_cfg, doc(cfg(...)))]` attribute, so
  mistakes should similarly be obvious

Release 0.8.7.

Closes #894

gherrit-pr-id: I74b8e9be0e6cb6e02552d2e1f985b490a7d37afe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-after-next-release Not blocking release, but we should do soon after release
Projects
None yet
Development

No branches or pull requests

1 participant