Skip to content

Don't show const in docs when it's not available #31329

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

Merged
merged 2 commits into from
Feb 3, 2016

Conversation

quodlibetor
Copy link
Contributor

Fixes #31098

AFAICT this is the only place where rustdoc explicitly checks if we are on stable before emitting content, so I can't tell if this is the sane way to handle this, or if anything else should be done to make sure that nobody forgets to remove this check when const is stabilized.

@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@alexcrichton
Copy link
Member

Does this break rendering other parts like *const T? I think the helper here may be used in more than one spot

@quodlibetor
Copy link
Contributor Author

It might, although I can't find it in render.rs and all the uses of hir::Constness that I could find were in building methods or functions, but I'll double check that some *cont T still shows up in the output.

Originally when I implemented this I added const filtering to the "build function or method" fns, but that required lying about the constness in the struct. If filtering in the render helper doesn't work out do you have an opinion on what I should do? It's not really lying about the constness of an object if it can't be made const in stable, is it?

@alexcrichton
Copy link
Member

After checking it looks like this is indeed only used for const fn, but I'd personally feel a little more comfortable at least if this were a bit more of a targeted conditional. Could this conditional be placed directly where const fn is being handled because that's what this is actually trying to apply to?

Also can this use the get_unstable_features_setting function in the compiler instead of reading the environment variable manually?

ConstnessSpace has no knowledge of the type of item it's modifying, so
hide the constness a level up.
@quodlibetor
Copy link
Contributor Author

Sort of like so?

@alexcrichton
Copy link
Member

@bors: r+ d59372b

Indeed, thanks!

@quodlibetor
Copy link
Contributor Author

Awesome! First rust PR :)

Manishearth added a commit to Manishearth/rust that referenced this pull request Feb 2, 2016
… r=alexcrichton

Fixes rust-lang#31098

AFAICT this is the only place where rustdoc explicitly checks if we are on stable before emitting content, so I can't tell if this is the sane way to handle this, or if anything else should be done to make sure that nobody forgets to remove this check when `const` is stabilized.
bors added a commit that referenced this pull request Feb 3, 2016
@bors bors merged commit d59372b into rust-lang:master Feb 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants