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

Stabilize param_attrs in Rust 1.39.0 #64010

Merged
merged 1 commit into from
Sep 21, 2019

Conversation

c410-f3r
Copy link
Contributor

@c410-f3r c410-f3r commented Aug 29, 2019

Stabilization proposal

I propose that we stabilize #![feature(param_attrs)].

Tracking issue: #60406
Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable).

What is stabilized

It is now possible to add outer attributes like #[cfg(..)] on formal parameters of functions, closures, and function pointer types. For example:

fn len(
    #[cfg(windows)] slice: &[u16],
    #[cfg(not(windows))] slice: &[u8],
) -> usize {
    slice.len()
}

What isn't stabilized

  • Documentation comments like /// Doc on parameters.

  • Code expansion of a user-defined #[proc_macro_attribute] macro used on parameters.

  • Built-in attributes other than cfg, cfg_attr, allow, warn, deny, and forbid. Currently, only the lints unused_variables and unused_mut have effect and may be controlled on parameters.

Motivation

The chief motivations for stabilizing param_attrs include:

  • Finer conditional compilation with #[cfg(..)] and linting control of variables.

  • Richer macro DSLs created by users.

  • External tools and compiler internals can take advantage of the additional information that the parameters provide.

For more examples, see the RFC.

Reference guide

In the grammar of function and function pointer, the grammar of variadic tails (...) and parameters are changed respectively from:

FnParam = { pat:Pat ":" }? ty:Type;
VaradicTail = "...";

into:

FnParam = OuterAttr* { pat:Pat ":" }? ty:Type;
VaradicTail = OuterAttr* "...";

The grammar of a closure parameter is changed from:

ClosureParam = pat:Pat { ":" ty:Type }?;

into:

ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?;

More generally, where there's a list of formal (value) parameters separated or terminated by , and delimited by ( and ). Each parameter in that list may optionally be prefixed by OuterAttr+.

Note that in all cases, OuterAttr* applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros.

History

  • On 2018-10-15, @Robbepop proposes RFC 2565, "Attributes in formal function parameter position".

  • On 2019-04-30, RFC 2565 is merged and the tracking issue is made.

  • On 2019-06-12, a partial implementation was completed. The implementation was done in #60669 by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril.

  • On 2019-07-29, #61238 was fixed in #61856. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk.

  • On 2019-08-02, a bug #63210 was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in fn print_arg in the pretty printer. In #63212, written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed.

  • This PR stabilizes param_attrs.

Tests

Possible future work

  • Custom attributes inside function parameters aren't currently supported but it is something being worked on internally.

  • Since documentation comments are syntactic sugar for #[doc(...)], it is possible to allow literal /// Foo comments on function parameters.

This report is a collaborative work with @Centril.

@rust-highfive

This comment has been minimized.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 29, 2019
@Centril
Copy link
Contributor

Centril commented Aug 29, 2019

r? @Centril

@rust-highfive rust-highfive assigned Centril and unassigned eddyb Aug 29, 2019
@Centril Centril added T-lang Relevant to the language team, which will review and decide on the PR/issue. relnotes Marks issues that should be documented in the release notes of the next release. A-attributes Area: Attributes (`#[…]`, `#![…]`) labels Aug 29, 2019
@Centril Centril added this to the 1.39 milestone Aug 29, 2019
@Centril
Copy link
Contributor

Centril commented Aug 29, 2019

Dear language team and the community at large. The above report gives an overview of the #[attr] param: type feature. I propose that we indeed do stabilize the feature accordingly.

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Aug 29, 2019

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

Concerns:

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-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Aug 29, 2019
Copy link
Contributor

@Centril Centril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me on the code changes itself when FCP completes.

@Centril Centril added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 29, 2019
@phansch
Copy link
Member

phansch commented Aug 30, 2019

Been waiting for this 🎉

Currently, only the lints unused_variables and unused_mut have effect, and may be controlled, on parameters.

How does that work? Was it a deliberate decision somewhere in the code or a coincidental result of the implementation? I'm just asking to find out if there's something we should be aware of with tool lints in Clippy.

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Aug 30, 2019

Question for @Centril and @c410-f3r --

You mention that procedural macros are not stabilized. Is there a test showing what happens when a procedural macro is applied? I presume that it generates a feature gate? Or is it considered an error?

Similarly, is there a test for lints that are intended to be disallowed?

@nikomatsakis
Copy link
Contributor

(Also, I should add, thanks for all your work on this. ❤️ )

@c410-f3r
Copy link
Contributor Author

c410-f3r commented Aug 30, 2019

@phansch

According to the RFC, this reduced number of allowed lint was initially proposed to be part of a minimum viable product. Nevertheless, more lints can be added in future releases.

@nikomatsakis

Currently, the compiler shows the the attribute 'some_proc_macro_attribute' is currently unknown to the compiler and may have meaning added to it in the future error. With #63468, it will be changed to expected an inert attribute, found an attribute macro and the message itself behaves as a feature gate.

@Centril
Copy link
Contributor

Centril commented Aug 31, 2019

@nikomatsakis

You mention that procedural macros are not stabilized. Is there a test showing what happens when a procedural macro is applied? I presume that it generates a feature gate? Or is it considered an error?

https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs sorta addresses this by using #[test] but I've hardened the tests somewhat in #64031.

Similarly, is there a test for lints that are intended to be disallowed?

The RFC does not specify a specific list of lints that should or should not be allowed but the two lints that are tested and accounted for seemed the most important. We'd need to do a deeper audit of all the lints to see which others could be relevant and that's probably not worth the time at the moment.

@Centril
Copy link
Contributor

Centril commented Aug 31, 2019

How does that work? Was it a deliberate decision somewhere in the code or a coincidental result of the implementation? I'm just asking to find out if there's something we should be aware of with tool lints in Clippy.

@phansch Reading #61856 is probably most relevant for Clippy development.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Sep 21, 2019
@bors
Copy link
Contributor

bors commented Sep 21, 2019

⌛ Testing commit 299d696 with merge 6c468ee...

bors added a commit that referenced this pull request Sep 21, 2019
Stabilize `param_attrs` in Rust 1.39.0

# Stabilization proposal

I propose that we stabilize `#![feature(param_attrs)]`.

Tracking issue: #60406
Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable).

## What is stabilized

It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example:

```rust
fn len(
    #[cfg(windows)] slice: &[u16],
    #[cfg(not(windows))] slice: &[u8],
) -> usize {
    slice.len()
}
```

## What isn't stabilized

* Documentation comments like `/// Doc` on parameters.

* Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters.

* Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters.

## Motivation

The chief motivations for stabilizing `param_attrs` include:

* Finer conditional compilation with `#[cfg(..)]` and linting control of variables.

* Richer macro DSLs created by users.

* External tools and compiler internals can take advantage of the additional information that the parameters provide.

For more examples, see the [RFC][rfc motivation].

## Reference guide

In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from:

```rust
FnParam = { pat:Pat ":" }? ty:Type;
VaradicTail = "...";
```

into:

```rust
FnParam = OuterAttr* { pat:Pat ":" }? ty:Type;
VaradicTail = OuterAttr* "...";
```

The grammar of a closure parameter is changed from:

```rust
ClosureParam = pat:Pat { ":" ty:Type }?;
```

into:

```rust
ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?;
```

More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`.

Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros.

## History

* On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position".

* On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made.

* On 2019-06-12, a partial implementation was completed. The implementation was done in [#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril.

* On 2019-07-29, [#61238][61238] was fixed in [#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk.

* On 2019-08-02, a bug [#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed.

* This PR stabilizes `param_attrs`.

## Tests

* [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs)

* [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs)

* [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs)

* [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs)

* [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns.

* [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs)

## Possible future work

* Custom attributes inside function parameters aren't currently supported but it is something being worked on internally.

* Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters.

[rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation
[rfc]: rust-lang/rfcs#2565
[60669]: #60669
[61856]: #61856
[63210]: #63210
[61238]: #61238
[63212]: #63212

This report is a collaborative work with @Centril.
@bors
Copy link
Contributor

bors commented Sep 21, 2019

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 21, 2019
@Centril
Copy link
Contributor

Centril commented Sep 21, 2019

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 21, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 21, 2019
Stabilize `param_attrs` in Rust 1.39.0

# Stabilization proposal

I propose that we stabilize `#![feature(param_attrs)]`.

Tracking issue: rust-lang#60406
Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable).

## What is stabilized

It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example:

```rust
fn len(
    #[cfg(windows)] slice: &[u16],
    #[cfg(not(windows))] slice: &[u8],
) -> usize {
    slice.len()
}
```

## What isn't stabilized

* Documentation comments like `/// Doc` on parameters.

* Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters.

* Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters.

## Motivation

The chief motivations for stabilizing `param_attrs` include:

* Finer conditional compilation with `#[cfg(..)]` and linting control of variables.

* Richer macro DSLs created by users.

* External tools and compiler internals can take advantage of the additional information that the parameters provide.

For more examples, see the [RFC][rfc motivation].

## Reference guide

In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from:

```rust
FnParam = { pat:Pat ":" }? ty:Type;
VaradicTail = "...";
```

into:

```rust
FnParam = OuterAttr* { pat:Pat ":" }? ty:Type;
VaradicTail = OuterAttr* "...";
```

The grammar of a closure parameter is changed from:

```rust
ClosureParam = pat:Pat { ":" ty:Type }?;
```

into:

```rust
ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?;
```

More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`.

Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros.

## History

* On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position".

* On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made.

* On 2019-06-12, a partial implementation was completed. The implementation was done in [rust-lang#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril.

* On 2019-07-29, [rust-lang#61238][61238] was fixed in [rust-lang#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk.

* On 2019-08-02, a bug [rust-lang#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [rust-lang#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed.

* This PR stabilizes `param_attrs`.

## Tests

* [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs)

* [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs)

* [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs)

* [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs)

* [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns.

* [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs)

## Possible future work

* Custom attributes inside function parameters aren't currently supported but it is something being worked on internally.

* Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters.

[rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation
[rfc]: rust-lang/rfcs#2565
[60669]: rust-lang#60669
[61856]: rust-lang#61856
[63210]: rust-lang#63210
[61238]: rust-lang#61238
[63212]: rust-lang#63212

This report is a collaborative work with @Centril.
bors added a commit that referenced this pull request Sep 21, 2019
Rollup of 9 pull requests

Successful merges:

 - #64010 (Stabilize `param_attrs` in Rust 1.39.0)
 - #64136 (Document From trait for LhsExpr in parser)
 - #64342 (factor out pluralisation remains after #64280)
 - #64347 (Add long error explanation for E0312)
 - #64621 (Add Compatibility Notes to RELEASES.md for 1.38.0)
 - #64632 (remove the extra comma after the match arm)
 - #64640 (No home directory on vxWorks)
 - #64641 (Exempt extern "Rust" from improper_ctypes)
 - #64642 (Fix the span used to suggest avoiding for-loop moves)

Failed merges:

r? @ghost
@bors bors merged commit 299d696 into rust-lang:master Sep 21, 2019
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Nov 11, 2019
Pkgsrc changes:
 * Remove patch which no longer applies (but what about RPATH?)
 * Adapt a few patches to changed files upstream.

Upstream changes:

Version 1.39.0 (2019-11-07)
===========================

Language
--------
- [You can now create `async` functions and blocks with `async fn`,
  `async move {}`, and `async {}` respectively, and you can now call
  `.await` on async expressions.][63209]
- [You can now use certain attributes on function, closure, and function
  pointer parameters.][64010] These attributes include `cfg`, `cfg_attr`,
  `allow`, `warn`, `deny`, `forbid` as well as inert helper attributes used
  by procedural macro attributes applied to items. e.g.
  ```rust
  fn len(
      #[cfg(windows)] slice: &[u16],
      #[cfg(not(windows))] slice: &[u8],
  ) -> usize {
      slice.len()
  }
  ```
- [You can now take shared references to bind-by-move patterns in the
  `if` guards of `match` arms.][63118] e.g.
  ```rust
  fn main() {
      let array: Box<[u8; 4]> = Box::new([1, 2, 3, 4]);

      match array {
          nums
  //      ---- `nums` is bound by move.
              if nums.iter().sum::<u8>() == 10
  //                 ^------ `.iter()` implicitly takes a reference to `nums`.
          => {
              drop(nums);
  //          ----------- Legal as `nums` was bound by move and so we have ownership.
          }
          _ => unreachable!(),
      }
  }
  ```

Compiler
--------
- [Added tier 3\* support for the `i686-unknown-uefi` target.][64334]
- [Added tier 3 support for the `sparc64-unknown-openbsd` target.][63595]
- [rustc will now trim code snippets in diagnostics to fit in your terminal.]
  [63402] **Note** Cargo currently doesn't use this feature. Refer to
  [cargo#7315][cargo/7315] to track this feature's progress.
- [You can now pass `--show-output` argument to test binaries to print the
  output of successful tests.][62600]

\* Refer to Rust's [platform support page][forge-platform-support] for more
information on Rust's tiered platform support.

Libraries
---------
- [`Vec::new` and `String::new` are now `const` functions.][64028]
- [`LinkedList::new` is now a `const` function.][63684]
- [`str::len`, `[T]::len` and `str::as_bytes` are now `const` functions.][63770]
- [The `abs`, `wrapping_abs`, and `overflowing_abs` numeric functions are
  now `const`.][63786]

Stabilized APIs
---------------
- [`Pin::into_inner`]
- [`Instant::checked_duration_since`]
- [`Instant::saturating_duration_since`]

Cargo
-----
- [You can now publish git dependencies if supplied with a `version`.]
  [cargo/7237]
- [The `--all` flag has been renamed to `--workspace`.][cargo/7241] Using
  `--all` is now deprecated.

Misc
----
- [You can now pass `-Clinker` to rustdoc to control the linker used
  for compiling doctests.][63834]

Compatibility Notes
-------------------
- [Code that was previously accepted by the old borrow checker, but rejected by
  the NLL borrow checker is now a hard error in Rust 2018.][63565] This was
  previously a warning, and will also become a hard error in the Rust 2015
  edition in the 1.40.0 release.
- [`rustdoc` now requires `rustc` to be installed and in the same directory to
  run tests.][63827] This should improve performance when running a large
  amount of doctests.
- [The `try!` macro will now issue a deprecation warning.][62672] It is
  recommended to use the `?` operator instead.
- [`asinh(-0.0)` now correctly returns `-0.0`.][63698] Previously this
  returned `0.0`.

[62600]: rust-lang/rust#62600
[62672]: rust-lang/rust#62672
[63118]: rust-lang/rust#63118
[63209]: rust-lang/rust#63209
[63402]: rust-lang/rust#63402
[63565]: rust-lang/rust#63565
[63595]: rust-lang/rust#63595
[63684]: rust-lang/rust#63684
[63698]: rust-lang/rust#63698
[63770]: rust-lang/rust#63770
[63786]: rust-lang/rust#63786
[63827]: rust-lang/rust#63827
[63834]: rust-lang/rust#63834
[63927]: rust-lang/rust#63927
[63933]: rust-lang/rust#63933
[63934]: rust-lang/rust#63934
[63938]: rust-lang/rust#63938
[63940]: rust-lang/rust#63940
[63941]: rust-lang/rust#63941
[63945]: rust-lang/rust#63945
[64010]: rust-lang/rust#64010
[64028]: rust-lang/rust#64028
[64334]: rust-lang/rust#64334
[cargo/7237]: rust-lang/cargo#7237
[cargo/7241]: rust-lang/cargo#7241
[cargo/7315]: rust-lang/cargo#7315
[`Pin::into_inner`]: https://doc.rust-lang.org/std/pin/struct.Pin.html#method.into_inner
[`Instant::checked_duration_since`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_duration_since
[`Instant::saturating_duration_since`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.saturating_duration_since
huitseeker added a commit to huitseeker/opaque-ke that referenced this pull request Nov 4, 2020
huitseeker added a commit to huitseeker/opaque-ke that referenced this pull request Nov 4, 2020
kevinlewi pushed a commit to kevinlewi/opaque-ke that referenced this pull request Nov 5, 2020
@yanfenglee
Copy link

When Custom attributes inside function parameters available? Is there a plan?

@c410-f3r
Copy link
Contributor Author

It is currently possible to parse custom attributes using procedural macros but they can't be present in the final TokenStream output.

@yanfenglee
Copy link

It is currently possible to parse custom attributes using procedural macros but they can't be present in the final TokenStream output.

Thanks for your reply, i don't quite understand "they can't be present in the final TokenStream output.", i want implement like this:

#[post("/path/{id}")]
async fn post_data(data: &PostData, #[path_varible("id")]id: i32, #[header("token")] token: String) -> Result<String, Error> {}

Is this possible?

@c410-f3r
Copy link
Contributor Author

c410-f3r commented Jan 27, 2021

Taking into consideration that #[post] is a procedural macro created by you, then yes. It is possible to parse #[path_varible("id")] and #[header("token")].

Thanks for your reply, i don't quite understand "they can't be present in the final TokenStream output.", i want implement like this:

#[post] is a procedural attribute macro that has the following signature: fn post(attrs: TokenStream, item: TokenStream) -> TokenStream;. Although [path_varible("id")] and #[header("token")] are present in item, they shouldn't be present in the TokenStream output.

Take a look at https://doc.rust-lang.org/reference/procedural-macros.html to learn more about procedural macros, use the syn crate for parsing and the quote crate for building tokens.

@yanfenglee
Copy link

Taking into consideration that #[post] is a procedural macro created by you, then yes. It is possible to parse #[path_varible("id")] and #[header("token")].

Thanks for your reply, i don't quite understand "they can't be present in the final TokenStream output.", i want implement like this:

#[post] is a procedural attribute macro that has the following signature: fn post(attrs: TokenStream, item: TokenStream) -> TokenStream;. Although [path_varible("id")] and #[header("token")] are present in item, they shouldn't be present in the TokenStream output.

Take a look at https://doc.rust-lang.org/reference/procedural-macros.html to learn more about procedural macros, use the syn crate for parsing and the quote crate for building tokens.

Thank you very much, i have already implemented #[post], and can not find examples used on function parameters, i will try later, thanks again

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 19, 2022
Formally implement let chains

## Let chains

My longest and hardest contribution since rust-lang#64010.

Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact, `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!`

With the changes proposed in this PR, it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words, do much of what the `if_chain` crate already does.

## Other considerations

* `if let guard` and `let ... else` features need special care and should be handled in a following PR.

* Irrefutable patterns are allowed within a let chain context

* ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~

cc rust-lang#53667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-param_attrs `#![feature(param_attrs)]` finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.