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

Standardize on "re-export" rather than "reexport" #47404

Merged
merged 3 commits into from
Jan 17, 2018
Merged

Standardize on "re-export" rather than "reexport" #47404

merged 3 commits into from
Jan 17, 2018

Conversation

carols10cents
Copy link
Member

While working on the book with our editors, it was brought to our attention that we're not consistent with when we use "re-export" versus "reexport". For the book, we've decided (with our editors) to go with "re-export"; in prose, I think that looks better. In code, I'm fine with "reexport".

However, the rustdoc generated section is currently "Reexports", so when we have a screenshot of generated documentation with the prose where we use "re-export", it's inconsistent.

It's too late to fix this for the book because we're using 1.21.0 for the output in the book, and it's really only one spot so it's not a huge deal, but I'd like to advocate for changing the documentation header so that a future edition of the book can be consistent.

The first commit here only changes the documentation section heading text and rustdoc documentation that references it. This is the commit that's most important to me.

The second commit changes error messages and associated tests to also be consistent with the use of re-export. This is the next most important commit to me, but I could be argued out of this one because then it won't match code like the macro_reexports feature name, which ostensibly should change to macro_re_exports to be most consistent but I didn't want to change code.

The last commit changes re-export anywhere else in prose: either in documentation comments or regular comments. This is least important as most of them aren't user-visible. Instances like these will likely sneak back in over time. I'm totally fine dropping this commit if anyone wants, but the hobgoblins made me do it and it sets a good example.

r? @steveklabnik

@carols10cents carols10cents added A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 13, 2018
@steveklabnik
Copy link
Member

[00:04:29] tidy error: /checkout/src/test/compile-fail/privacy/legacy-ctor-visibility.rs:22: line longer than 100 chars

r=me after tidy is happy

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 15, 2018
@carols10cents
Copy link
Member Author

@bors r=steveklabnik

@bors
Copy link
Contributor

bors commented Jan 15, 2018

📌 Commit e168aa3 has been approved by steveklabnik

@carols10cents carols10cents added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 15, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Jan 17, 2018
… r=steveklabnik

Standardize on "re-export" rather than "reexport"

While working on the book with our editors, it was brought to our attention that we're not consistent with when we use "re-export" versus "reexport". For the book, we've decided (with our editors) to go with "re-export"; in prose, I think that looks better. In code, I'm fine with "reexport".

However, the rustdoc generated section is currently "Reexports", so when we have a screenshot of generated documentation with the prose where we use "re-export", it's inconsistent.

It's too late to fix this for the book because we're using 1.21.0 for the output in the book, and it's really only one spot so it's not a huge deal, but I'd like to advocate for changing the documentation header so that a future edition of the book can be consistent.

The first commit here only changes the documentation section heading text and rustdoc documentation that references it. This is the commit that's most important to me.

The second commit changes error messages and associated tests to also be consistent with the use of re-export. This is the next most important commit to me, but I could be argued out of this one because then it won't match code like the `macro_reexports` feature name, which ostensibly should change to `macro_re_exports` to be most consistent but I didn't want to change code.

The last commit changes re-export anywhere else in prose: either in documentation comments or regular comments. This is least important as most of them aren't user-visible. Instances like these will likely sneak back in over time. I'm totally fine dropping this commit if anyone wants, but [the hobgoblins made me do it](http://www.bartleby.com/100/420.47.html) and it sets a good example.

r? @steveklabnik
kennytm added a commit to kennytm/rust that referenced this pull request Jan 17, 2018
… r=steveklabnik

Standardize on "re-export" rather than "reexport"

While working on the book with our editors, it was brought to our attention that we're not consistent with when we use "re-export" versus "reexport". For the book, we've decided (with our editors) to go with "re-export"; in prose, I think that looks better. In code, I'm fine with "reexport".

However, the rustdoc generated section is currently "Reexports", so when we have a screenshot of generated documentation with the prose where we use "re-export", it's inconsistent.

It's too late to fix this for the book because we're using 1.21.0 for the output in the book, and it's really only one spot so it's not a huge deal, but I'd like to advocate for changing the documentation header so that a future edition of the book can be consistent.

The first commit here only changes the documentation section heading text and rustdoc documentation that references it. This is the commit that's most important to me.

The second commit changes error messages and associated tests to also be consistent with the use of re-export. This is the next most important commit to me, but I could be argued out of this one because then it won't match code like the `macro_reexports` feature name, which ostensibly should change to `macro_re_exports` to be most consistent but I didn't want to change code.

The last commit changes re-export anywhere else in prose: either in documentation comments or regular comments. This is least important as most of them aren't user-visible. Instances like these will likely sneak back in over time. I'm totally fine dropping this commit if anyone wants, but [the hobgoblins made me do it](http://www.bartleby.com/100/420.47.html) and it sets a good example.

r? @steveklabnik
bors added a commit that referenced this pull request Jan 17, 2018
@bors bors merged commit e168aa3 into rust-lang:master Jan 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants