syntax: enable attributes and cfg on struct fields #38814

Ralith · 2017-01-04T04:45:14Z

This enables conditional compilation of field initializers in a struct literal, simplifying construction of structs whose fields are themselves conditionally present. For example, the intializer for the constant in the following becomes legal, and has the intuitive effect:

struct Foo {
    #[cfg(unix)]
    bar: (),
}

const FOO: Foo = Foo {
    #[cfg(unix)]
    bar: (),
};

It's not clear to me whether this calls for the full RFC process, but the implementation was simple enough that I figured I'd begin the conversation with code.

rust-highfive · 2017-01-04T04:45:27Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

nrc · 2017-01-04T07:52:36Z

cc @rust-lang/lang are we happy to add this? Given that we allow cfg on struct fields in decls, it makes sense to me to allow them in struct lits. This seems minor enough that we don't need an RFC. Thoughts?

nrc · 2017-01-04T07:54:00Z

Hmm, actually this allows all attributes on fields in struct lits. That still seems ok to me, but not as much of a slam dunk as I thought.

nrc · 2017-01-04T07:55:00Z

@Ralith the code looks OK to me, it does need a few tests though.

Ralith · 2017-01-04T07:57:10Z

Re: other attributes: Would it make sense to be more restrictive? Are there any other locations in the language where cfg is permitted but other attributes are not?

Beginning work on tests now.

aturon · 2017-01-04T17:14:05Z

@nrc I'm in favor of this change. In general, we've been moving to add attributes everywhere unless there's ambiguity/hard to discern meaning (as we saw with expressions).

Mark-Simulacrum · 2017-01-04T19:22:26Z

Is using cfg on expressions and/or statements stable? It seems like this might cause problems if that isn't available; since that would require duplicating entire functions for each platform combination.

In general, though, I'm in favor. I'm slightly concerned we're moving in the direction of C/C++, where libraries like OpenSSL have a large quantity of fields being "optional" and disabled on certain platforms and/or with certain features, which to some extent heightens complexity for users. I believe @sfackler might have some relevant thoughts on this as he manages the bindings for OpenSSL.

sfackler · 2017-01-04T19:25:37Z

This doesn't really matter for rust-openssl since we never actually create those structs. I definitely agree that conditionally defining public-facing fields is a pain, though doing that for enum variants is fairly common. On the other hand, conditionally defining internal fields can be pretty nice (e.g. https://github.com/brson/error-chain/blob/master/src/lib.rs#L458)

Ralith · 2017-01-04T19:36:28Z

For illustration, this patch was inspired by the awkwardness of my employing exactly that pattern in my experimental tokio-based window/input system binding, in which I'm trying to provide a uniform interface dispatching over a set of concrete implementations that differs between platforms. Perhaps there's a better way to accomplish this, but this certainly seems to be the most obvious.

Notably, this change alone reduces the need for duplicating entire functions (e.g. init_evdev) in the linked code, though I was able to keep the overhead linear in the number of backends.

nikomatsakis · 2017-01-04T20:36:00Z

I am in favor of this change.

nikomatsakis · 2017-01-04T20:37:47Z

@rfcbot fcp merge

The proposal here is to allow attributes on struct fields. This is a relatively small extension to the general trend of allowing attributes on statements and so forth. @nrc is proposing that we approve this (with a feature gate, naturally) without an FCP. I'm in favor since an RFC feels like overkill and we have a big enough backlog as it is. What do you think, @rust-lang/lang?

rfcbot · 2017-01-04T20:51:13Z

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, 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.

nrc · 2017-01-05T00:18:32Z

Re: other attributes: Would it make sense to be more restrictive? Are there any other locations in the language where cfg is permitted but other attributes are not?

I do not think this makes sense, we should allow all attributes, including cfg (sorry for the confusion in my earlier comments).

@Ralith could you add a feature gate to this PR please?

Ralith · 2017-01-05T05:48:47Z

Added a feature gate struct_field_attributes and added previously missing adjustments to Visitor to walk the new attribute location.

jseyfried · 2017-01-05T06:00:25Z

src/libsyntax/visit.rs

@@ -659,6 +659,7 @@ pub fn walk_expr<'a, V: Visitor<'a>>(visitor: &mut V, expression: &'a Expr) {
        ExprKind::Struct(ref path, ref fields, ref optional_base) => {
            visitor.visit_path(path, expression.id);
            for field in fields {
+                walk_list!(visitor, visit_attribute, field.attrs.iter());


I believe field.attrs.iter() can be just field.attrs.

It cannot. ThinVec does not implement IntoIterator. &ThinVec also does not, leaving only this approach.

Oh right -- field.attrs.deref() should work then, or just leave as is.

pnkfelix · 2017-01-05T20:36:08Z

@rfcbot concern struct-fields-in-patterns

Is the proposed extension intended to cover fields in patterns as well? I cannot tell from skimming the code, and in any case I do not see any test coverage of fields in patterns.

By that "fields in patterns" mean the following:

struct S { x: i32, y: i32 }
fn main() {
    let s = S { x: 10, y: 20 };
    match s {
        S {
            x: 11, // this is a field in a pattern ...
            y: the_y // ... and this is a field in a binding pattern
        } => println!("the_y: {}", the_y),
        
        S { x: the_x, y: 20 } => println!("the_x: {}", the_x),
        
        S { .. } => {}
    }
}

(and of course such patterns can also be used with let, if let , et cetera)

nikomatsakis · 2017-01-05T21:53:27Z

@pnkfelix good question! Seems like the answer should be "yes, those ought to be supported too", right? I guess I expect fields to be configurable at all places where fields appear (definition, struct literal, patterns)

Ralith · 2017-01-06T08:26:58Z

@pnkfelix That was not the intention, but I agree that it makes sense. I'm working on implementing it now. Getting #[cfg(...)] working there is taking slightly more effort than expected.

jseyfried · 2017-01-07T22:45:38Z

src/libsyntax/config.rs

+                    .collect();
+                ast::ExprKind::Struct(path, fields, base)
+            }
+            expr_kind => expr_kind,


nit: _ => expr_kind,

jseyfried · 2017-01-07T22:46:37Z

src/libsyntax/config.rs

+        match pat_kind {
+            ast::PatKind::Struct(path, fields, etc) => {
+                let fields = fields.into_iter()
+                    .filter_map(|a| self.configure_struct_pat_field(a))


I believe you could derive HasAttrs for Spanned<ast::FieldPat>, remove configure_struct_pat_field, and gated feature check in this closure.

jseyfried · 2017-01-07T22:49:22Z

src/libsyntax/config.rs

+        self.configure(node).map(|node| Spanned { span: span, node: node })
+    }
+
+    pub fn configure_pat_kind(&mut self, pat_kind: ast::PatKind) -> ast::PatKind {


I think this would be easier to use as configure_pat.

jseyfried · 2017-01-07T22:51:38Z

src/libsyntax/config.rs

+        let mut pattern = pattern.unwrap();
+        pattern.node = self.configure_pat_kind(pattern.node);
+        println!("{:#?}", pattern);
+        fold::noop_fold_pat(P(pattern), self)


It's more efficient and idiomatic to do the following here:

pattern.map(|mut pattern| { // ... pattern })

(if you did configure_pat instead of configure_pat_kind, the .map would be there)

jseyfried · 2017-01-07T22:52:07Z

src/libsyntax/ext/expand.rs

@@ -679,15 +679,18 @@ impl<'a, 'b> Folder for InvocationCollector<'a, 'b> {
    }

    fn fold_pat(&mut self, pat: P<ast::Pat>) -> P<ast::Pat> {
+        let mut pat = pat.unwrap();
+        pat.node = self.cfg.configure_pat_kind(pat.node);


Same here, also would be solved by having configure_pat.

jseyfried

@Ralith thanks!
Could you add a feature gate test?
Other than that, r=me pending #38814 (comment).

jseyfried · 2017-01-08T09:59:19Z

src/libsyntax/config.rs

+                                          "attributes on struct literal fields are unstable");
+                err.emit();
+            }
+        }


Perhaps we could refactor out this gated feature check (and the one below) into self.visit_struct_field_attrs() (c.f. self.visit_expr_attrs()) and then refactor away self.configure_struct_expr_field() and self.configure_struct_pat_field()?

jseyfried · 2017-01-08T10:03:40Z

src/libsyntax/config.rs

+                        .collect();
+                    pattern.node = ast::PatKind::Struct(path, fields, etc);
+                }
+                _ => (),


nit: _ => {} is more idiomatic (or if let)

jseyfried · 2017-01-11T08:01:35Z

This PR is blocked on #38814 (comment).
@pnkfelix This now supports #[cfg] on struct field patterns.
cc @withoutboats

pnkfelix · 2017-01-11T17:12:34Z

@rfcbot resolved struct-fields-in-patterns

pnkfelix · 2017-01-11T17:12:46Z

@rfcbot reviewed

withoutboats · 2017-01-11T22:28:29Z

@rfcbot reviewed

jseyfried · 2017-01-12T05:36:15Z

@bors r+

bors · 2017-01-12T05:36:16Z

📌 Commit 7972c19 has been approved by jseyfried

bors · 2017-01-12T16:45:34Z

⌛ Testing commit 7972c19 with merge 78ccca8...

bors · 2017-01-12T18:31:53Z

💔 Test failed - status-travis

alexcrichton · 2017-01-12T18:36:03Z

@bors: retry * osx linker segfaulted #38878

…

On Thu, Jan 12, 2017 at 10:31 AM, bors ***@***.***> wrote: 💔 Test failed - status-travis <https://travis-ci.org/rust-lang/rust/builds/191366421> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#38814 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD95A9rlDn0bPkS9WXIyx2_6agW51Wtks5rRnGbgaJpZM4LaSVF> .

bors · 2017-01-12T20:43:39Z

⌛ Testing commit 7972c19 with merge e357178...

syntax: enable attributes and cfg on struct fields This enables conditional compilation of field initializers in a struct literal, simplifying construction of structs whose fields are themselves conditionally present. For example, the intializer for the constant in the following becomes legal, and has the intuitive effect: ```rust struct Foo { #[cfg(unix)] bar: (), } const FOO: Foo = Foo { #[cfg(unix)] bar: (), }; ``` It's not clear to me whether this calls for the full RFC process, but the implementation was simple enough that I figured I'd begin the conversation with code.

bors · 2017-01-12T22:51:55Z

☀️ Test successful - status-appveyor, status-travis
Approved by: jseyfried
Pushing e357178 to master...

colin-kiegel · 2017-04-07T21:01:06Z

I couldn't find a tracking issue to stabilise this. How is the procedure for stabilisation? This would be really nice to have! :-)

mbrubeck · 2017-05-01T20:59:57Z

Submitted #41681 as a tracking issue for stability.

rust-highfive assigned nrc Jan 4, 2017

nrc added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Jan 4, 2017

Ralith force-pushed the cfg-fields branch from 0e6ec3a to 22235f7 Compare January 4, 2017 09:23

jseyfried reviewed Jan 5, 2017

View reviewed changes

Ralith changed the title ~~syntax: configurable struct literal fields~~ syntax: enable attributes and cfg on struct fields Jan 7, 2017

Ralith force-pushed the cfg-fields branch from bde154b to 88887db Compare January 7, 2017 22:15

jseyfried reviewed Jan 7, 2017

View reviewed changes

jseyfried assigned jseyfried and unassigned nrc Jan 8, 2017

jseyfried reviewed Jan 8, 2017

View reviewed changes

syntax: struct field attributes and cfg

7972c19

Ralith force-pushed the cfg-fields branch from 010cb91 to 7972c19 Compare January 12, 2017 05:34

bors merged commit 7972c19 into rust-lang:master Jan 12, 2017

This was referenced Jan 12, 2017

Implement kind="static-nobundle" (RFC 1717) #38426

Merged

calling convention for MSP430 interrupts #38465

Merged

est31 mentioned this pull request Jan 12, 2017

Make tidy check for lang gate tests #38914

Merged

This was referenced Jan 12, 2017

LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support #38699

Merged

Implement #[proc_macro_attribute] #38842

Merged

jseyfried added relnotes Marks issues that should be documented in the release notes of the next release. and removed relnotes Marks issues that should be documented in the release notes of the next release. labels Jan 17, 2017

Emilgardis mentioned this pull request Jan 28, 2017

Document all features in the reference #38643

Closed

17 tasks

This was referenced Apr 19, 2017

Add rustfmt support for attribute on struct literal field #41392

Closed

Add support for attribute on struct literal field rust-lang/rustfmt#1462

Closed

mbrubeck added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed B-unstable Blocker: Implemented in the nightly compiler and unstable. labels May 1, 2017

mbrubeck mentioned this pull request May 1, 2017

Tracking issue for struct_field_attributes #41681

Closed

4 tasks

rbtying mentioned this pull request May 12, 2017

struct_field_attributes disappear when running rustfmt rust-lang/rustfmt#1535

Closed

ehuss mentioned this pull request May 4, 2022

Remove OuterAttributes for StructPatternEtCetera rust-lang/reference#1200

Closed

syntax: enable attributes and cfg on struct fields #38814

syntax: enable attributes and cfg on struct fields #38814

Conversation

Ralith commented Jan 4, 2017 • edited Loading

rust-highfive commented Jan 4, 2017

nrc commented Jan 4, 2017

nrc commented Jan 4, 2017

nrc commented Jan 4, 2017

Ralith commented Jan 4, 2017 • edited Loading

aturon commented Jan 4, 2017

Mark-Simulacrum commented Jan 4, 2017

sfackler commented Jan 4, 2017

Ralith commented Jan 4, 2017 • edited Loading

nikomatsakis commented Jan 4, 2017

nikomatsakis commented Jan 4, 2017

rfcbot commented Jan 4, 2017 • edited by nrc Loading

nrc commented Jan 5, 2017

Ralith commented Jan 5, 2017

jseyfried Jan 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pnkfelix commented Jan 5, 2017

nikomatsakis commented Jan 5, 2017

Ralith commented Jan 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jseyfried left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jseyfried commented Jan 11, 2017

pnkfelix commented Jan 11, 2017

pnkfelix commented Jan 11, 2017

withoutboats commented Jan 11, 2017

jseyfried commented Jan 12, 2017

bors commented Jan 12, 2017

bors commented Jan 12, 2017

bors commented Jan 12, 2017

alexcrichton commented Jan 12, 2017 via email

bors commented Jan 12, 2017

bors commented Jan 12, 2017

colin-kiegel commented Apr 7, 2017

mbrubeck commented May 1, 2017

Ralith commented Jan 4, 2017 •

edited

Loading

Ralith commented Jan 4, 2017 •

edited

Loading

Ralith commented Jan 4, 2017 •

edited

Loading

rfcbot commented Jan 4, 2017 •

edited by nrc

Loading

jseyfried Jan 5, 2017 •

edited

Loading