-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
2024 edition prelude item docs are not inlined, and cause some duplication and confusion #136102
Comments
@rustbot labels +I-libs-api-nominated What's the situation on being able to give canonical paths to the macros and attribute macros here?: https://doc.rust-lang.org/core/prelude/v1/index.html#macros While reverting the use of the |
Worth mentioning, if we did ever need to remove something from an edition prelude that remained in older preludes, another way we might do it, rather than having a |
@rustbot labels -I-libs-api-nominated This was discussed in the libs-api call today. Libs-api is OK with the strategy of reverting the If we ever did need to remove something from a prelude over an edition, the strategy of elaborating the import also sounded right to people. On the matter of giving paths to these macros, the team also felt warmly about that. One matter that was raised was the question of whether this might affect what is brought into scope for users of the Fortunately, it doesn't seem this is the case. Firstly, the behavior that would have given rise to this is exclusive to Rust 2015. Quoting the Reference:
But, moreover, even without a //@ edition: 2015
#![no_implicit_prelude]
#[derive()]
struct S;
fn main() {
let _ = todo!();
} On the call, the decision of the team was that PRs adding paths to these macros should be nominated for libs-api so that these can be handled via FCP. |
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
…ratt Remove the common prelude module This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems. Closes rust-lang#136102
Rollup merge of rust-lang#136886 - ehuss:remove-prelude-common, r=jhpratt Remove the common prelude module This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems. Closes rust-lang#136102
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
…ratt Remove the common prelude module This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems. Closes rust-lang#136102
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
…ratt Remove the common prelude module This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems. Closes rust-lang#136102
This fixes the issues described in rust-lang#136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
#116016 made some changes to how the prelude items are structured which causes some problems with how the documentation is generated:
derive
leads you to a page that says the attribute is unstable. This is misleading, it is the re-export that is unstable. The search index only shows one entry, and the unstable page doesn't tell you why it is unstable.derive
. It will lead you to https://doc.rust-lang.org/1.84.0/core/prelude/rust_2024/attr.derive.html which says it is unstable.doc(no_inline)
.I would like to propose that after #134272 merges to undo the introduction of the
common
module, and revert it back to the previous state whererust_2024
re-exportsv1
withdoc(no_inline)
. Unfortunately this will break/delete existing pages like https://doc.rust-lang.org/core/prelude/rust_2024/attr.derive.html. I'm personally fine with that.The text was updated successfully, but these errors were encountered: