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

Allow macros in type positions #27245

Closed
pnkfelix opened this issue Jul 23, 2015 · 19 comments
Closed

Allow macros in type positions #27245

pnkfelix opened this issue Jul 23, 2015 · 19 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@pnkfelix
Copy link
Member

Tracking issue for rust-lang/rfcs#873

@steveklabnik steveklabnik added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Aug 13, 2015
@alex
Copy link
Member

alex commented Nov 22, 2015

The feature gate for this points at #27336, should it point here instead?

@durka
Copy link
Contributor

durka commented Feb 23, 2016

How is this going? Is anything on fire yet?

nodakai added a commit to nodakai/rust that referenced this issue Mar 26, 2016
Signed-off-by: NODA, Kai <nodakai@gmail.com>
bors added a commit that referenced this issue Mar 27, 2016
nodakai added a commit to nodakai/rust that referenced this issue Mar 27, 2016
Signed-off-by: NODA, Kai <nodakai@gmail.com>
bors added a commit that referenced this issue Mar 27, 2016
@regexident
Copy link
Contributor

Is there any review/stability status on this feature by any chance?

@tikue
Copy link
Contributor

tikue commented May 21, 2016

Any update on this?

@huonw huonw added T-lang Relevant to the language team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. I-nominated labels May 21, 2016
@huonw
Copy link
Member

huonw commented May 21, 2016

cc @rust-lang/lang. This seems like a constrained extension to macros, that we could consider stabilising.

@durka
Copy link
Contributor

durka commented May 21, 2016

There's an issue re interaction with deriving, see #32950, but I think it's minor.

@aturon
Copy link
Member

aturon commented May 23, 2016

Going to FCP for this feature seems good to me. If people are using it successfully (or have found bugs!) please say so :-)

@nrc
Copy link
Member

nrc commented May 23, 2016

+1 to stabilising. There are still a few issues with type macros, but just bugs, and nothing major that I'm aware of.

@durka
Copy link
Contributor

durka commented Jun 17, 2016

Did the lang team decide to FCP or wait?

@aturon aturon added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jun 21, 2016
@aturon
Copy link
Member

aturon commented Jun 21, 2016

We went to FCP. Apologies @durka for the dropped administrative work recently -- all of the Mozilla folks just traveled to London for a week and the preparations for that resulted in some balls being dropped.

@aturon
Copy link
Member

aturon commented Jun 21, 2016

This feature is in its final comment period for stabilization (in 1.11).

@slash3g
Copy link
Contributor

slash3g commented Aug 21, 2016

rustc 1.11 still reports type macros as unstable. Is there any chance of having this feature stabilized in 1.12?

@aturon
Copy link
Member

aturon commented Aug 22, 2016

Yes, it's ready for immediate stabilization. Anyone should feel free to open a stabilization PR and ping me on it.

@nikomatsakis
Copy link
Contributor

Indeed I am slow in writing it up, but the @rust-lang/lang team decided formally to stabilize this feature (as @aturon commented). Horray!

@nikomatsakis nikomatsakis added E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Aug 22, 2016
@nikomatsakis
Copy link
Contributor

I am tagging the issue with E-mentor because I would be happy to mentor someone through the process of implementing a stabilization PR.

@nikomatsakis nikomatsakis added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue. labels Aug 22, 2016
@slash3g
Copy link
Contributor

slash3g commented Aug 22, 2016

@nikomatsakis I don't have experience with rustc internals, but I'd be happy to try to implement the stabilization PR. :-)

@nikomatsakis
Copy link
Contributor

@slash3g ok, basically all you have to do is to modify expand_type in libsyntax/ext/expand.rs and basically remove the if from this code:

pub fn expand_type(t: P<ast::Ty>, fld: &mut MacroExpander) -> P<ast::Ty> {
    let t = match t.node.clone() {
        ast::TyKind::Mac(mac) => {
            if fld.cx.ecfg.features.unwrap().type_macros {
                expand_mac_invoc(mac, None, Vec::new(), t.span, fld)
            } else {
                feature_gate::emit_feature_err(
                    &fld.cx.parse_sess.span_diagnostic,
                    "type_macros",
                    t.span,
                    feature_gate::GateIssue::Language,
                    "type macros are experimental");

                DummyResult::raw_ty(t.span)
            }
        }
        _ => t
    };

    fold::noop_fold_ty(t, fld)
}

you also need to change this declaration from libsyntax/feature_gate.rs and move it to be "accepted" (there is a section of "accepted" features below in the file):

    // Allows macros to appear in the type position.
    (active, type_macros, "1.3.0", Some(27245)),

@durka
Copy link
Contributor

durka commented Aug 23, 2016

Also remove #![feature(type_macros)] from any tests that mention it.

@slash3g
Copy link
Contributor

slash3g commented Aug 24, 2016

Ok, I've removed the check on the feature gate in expand_type, updated the tests and moved the declaration in libsyntax/feature_gate.rs.
Just two questions:

  1. should I bump the version number in the declaration to "1.12.0"? (or maybe "1.13.0", it's not clear to me if this commit will be backported to the current beta)
  2. should I reference this issue in the commit message? I've put "Closes Allow macros in type positions #27245" for now, I don't know if this convention is ok for this project.
    Thanks!

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. B-unstable Blocker: Implemented in the nightly compiler and unstable. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests