Skip to content

Tracking issue for Consistent no-prelude attribute (RFC 501) #20561

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
aturon opened this issue Jan 5, 2015 · 10 comments
Closed

Tracking issue for Consistent no-prelude attribute (RFC 501) #20561

aturon opened this issue Jan 5, 2015 · 10 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-tracking-design-concerns Status: There are blocking design concerns. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Jan 5, 2015

rust-lang/rfcs#501

@aturon aturon added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Jan 5, 2015
@aturon
Copy link
Member Author

aturon commented Jan 5, 2015

cc @Kimundi

@bombless
Copy link
Contributor

bombless commented Mar 5, 2015

I think in theory primitive type definitions come from std::*.
So if no_std or no_prelude is on there should not been primitive type definitions.
And I suggest we make alias of primitive types to a place like std::primitive_definition::*, so we write codes below to perform as no_std today:

#![no_std]
use std::primitive_definition::*

I know this change sounds trivial but current behavior is pretty ugly, see #22093
cc @mahkoh

@alexcrichton alexcrichton added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 11, 2015
@steveklabnik
Copy link
Member

Triage: so. This RFC happened pre-1.0, yet never landed. And it seems no_implicit_prelude does work on stable today. So, this would have to not be a re-naming, but a deprecation + new name?

@Kimundi
Copy link
Member

Kimundi commented Dec 3, 2016

Seems there has been a patch to implement this early this year, but it bitrottet: #32025

@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 22, 2017
@pnkfelix
Copy link
Member

pnkfelix commented Mar 4, 2022

@rustbot label +S-tracking-design-concerns

As noted by @petrochenkov here and @oli-obk here, its not clear if this change is still well-motivated.

@rustbot rustbot added the S-tracking-design-concerns Status: There are blocking design concerns. label Mar 4, 2022
@pnkfelix
Copy link
Member

pnkfelix commented Mar 4, 2022

Discussed at today's T-compiler backlog bonanza.

I propose we close this until someone who can drive it comes forward and can motivate doing this at this point.

@rfcbot fcp close

@rfcbot
Copy link
Collaborator

rfcbot commented Mar 4, 2022

Team member @pnkfelix has proposed to close this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. labels Mar 4, 2022
@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels May 19, 2022
@rfcbot
Copy link
Collaborator

rfcbot commented May 19, 2022

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels May 29, 2022
@rfcbot
Copy link
Collaborator

rfcbot commented May 29, 2022

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label May 29, 2022
@lcnr lcnr removed the to-announce Announce this issue on triage meeting label May 30, 2022
@lcnr
Copy link
Contributor

lcnr commented May 30, 2022

I propose we close this until someone who can drive it comes forward and can motivate doing this at this point.

@lcnr lcnr closed this as completed May 30, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-tracking-design-concerns Status: There are blocking design concerns. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

10 participants