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

Headings in rustdoc markdown chunks should have anchors & with copyable links #12681

Closed
huonw opened this issue Mar 4, 2014 · 0 comments
Closed
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@huonw
Copy link
Member

huonw commented Mar 4, 2014

E.g. the section documenting the {..., select, ...} formatting specifier is buried deep inside the doc page: http://static.rust-lang.org/doc/master/std/fmt/index.html

It would be nice if the headings had anchors (with links nearby, so accessing the appropriate anchor for a link was easy); the above could be, say, http://static.rust-lang.org/doc/master/std/fmt/index.html#sec.select and it would jump straight to the relevant part.

@huonw huonw added the A-rustdoc label Mar 4, 2014
bors added a commit that referenced this issue Mar 6, 2014
This commit adds a appear-on-over link to all section headers to generated
documentation. Each header also receives an id now, even those generated through
markdown. The purpose of this is to provide easy to link to sections.

This modifies the default header markdown generation because the default id
added looks like "toc_NN" which is difficult to reconcile among all sections (by
default each section gets a "toc_0" id), and it's also not very descriptive of
where you're going.

This chooses to adopt the github-style anchors by taking the contents of the
title and hyphen-separating them (after lower casing).

Closes #12681
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 13, 2024
Let `qualify_min_const_fn` deal with drop terminators

Fixes rust-lang#12677

The `method_accepts_droppable` check that was there seemed overly conservative.
> Returns true if any of the method parameters is a type that implements `Drop`.
> The method can't be made const then, because `drop` can't be const-evaluated.

Accepting parameters that implement `Drop` should still be fine as long as the parameter isn't actually dropped, as is the case in the linked issue where the droppable is moved into the return place. This more accurate analysis ("is there a `drop` terminator") is already done by `qualify_min_const_fn` [here](https://github.com/rust-lang/rust-clippy/blob/f5e250180c342bb52808c9a934c962a8fe40afc7/clippy_utils/src/qualify_min_const_fn.rs#L298), so I don't think this additional check is really necessary?

Fixing the other, second case in the linked issue was only slightly more involved, since `Vec::new()` is a function call that has the ability to panic, so there must be a `drop()` terminator for cleanup, however we should be able to freely ignore that. [Const checking ignores cleanup blocks](https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/transform/check_consts/check.rs#L382-L388), so we should, too?

r? `@Jarcho`

----

changelog: [`missing_const_for_fn`]: continue linting on fns with parameters implementing `Drop` if they're not actually dropped
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant