Skip to content

Guide: Make add_three_times_four() public #16268

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

Conversation

cakebaker
Copy link
Contributor

To avoid a compilation error when running the tests the function has to be public.

@steveklabnik
Copy link
Member

Thanks!

@steveklabnik
Copy link
Member

Unsure what to do here. I guess this must be marked ignore? 😦

@huonw
Copy link
Member

huonw commented Aug 19, 2014

It should work if you add a hidden # fn main() {} to override rustdoc's automatic insertion, i.e.

```rust
# fn main() {}
pub fn add_three_times_four(...) { ... }
```

@steveklabnik
Copy link
Member

ah ha! I knew there would be a way.

@steveklabnik
Copy link
Member

@cakebaker would you mind fixing it in the way @huonw suggested? r=me when that's done.

@cakebaker cakebaker force-pushed the make_fn_add_three_times_four_public branch from 642b4ad to 1777047 Compare August 23, 2014 13:07
@cakebaker
Copy link
Contributor Author

@steveklabnik done

@steveklabnik
Copy link
Member

Thank you! Travis failures seem unrelated...

bors added a commit that referenced this pull request Aug 23, 2014
…blic, r=steveklabnik

To avoid a compilation error when running the tests the function has to be public.
@bors bors closed this Aug 23, 2014
@bors bors merged commit 1777047 into rust-lang:master Aug 23, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 8, 2024
…, r=Veykril

Remove completion limit for trait importing method completions

Fixes rust-lang/rust-analyzer#16075

The < 3 char limit never applied to methods and the amount of completions generated due this is not absolutely massive as not all traits in a project are ever applicable so there is little reason to employ the limit here. Especially as it limits the number of traits we consider, not items (after my changes yesterday), and the number of traits is not the slowing factor here. Tested this in r-a where we have ~800 traits project wide and even when ~260 are applicable there was no noticable slow down from it.
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