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

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

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: A tracking issue for an RFC or an unstable feature. 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: A tracking issue for an RFC or an unstable feature. 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

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

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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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