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 RFC#1685: Deprecate anonymous parameters #41686

Closed
3 tasks done
aturon opened this issue May 1, 2017 · 34 comments
Closed
3 tasks done

Tracking issue for RFC#1685: Deprecate anonymous parameters #41686

aturon opened this issue May 1, 2017 · 34 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-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented May 1, 2017

This is a tracking issue for the RFC "Deprecate anonymous parameters " (rust-lang/rfcs#1685).

Steps:

  • Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
  • Adjust documentation (see instructions on forge)

Unresolved questions:

  • The precise deprecation strategy
@aturon aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels May 1, 2017
@est31
Copy link
Member

est31 commented May 1, 2017

I could work on this. From reading the RFC discussion, I think the "soft" deprecation strategy has been chosen? So on the compiler side, we'll need an allow by default (deprecation) lint for anonymous parameters, right?

@aturon
Copy link
Member Author

aturon commented May 1, 2017

@est31 Awesome! And yes, that's correct. This will be most effective if we add the lint to Clippy as well.

(The open question is around the criteria for moving to a warn-by-default strategy in the future.)

est31 added a commit to est31/rust that referenced this issue May 2, 2017
Removes occurences of anonymous parameters from the
rustc codebase, as they are to be deprecated.

See issue rust-lang#41686 and RFC 1685.
@est31
Copy link
Member

est31 commented May 2, 2017

About the clippy lint, I'll leave that to someone else. Given #41692, it should be mostly copy paste, but maybe with official rust claiming the lint name one has to chose another one. No idea.

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 2, 2017
Add a lint to disallow anonymous parameters

Adds a (allow by default) lint to disallow anonymous parameters, like it was decided in RFC 1685 (rust-lang/rfcs#1685).

cc tracking issue rust-lang#41686
frewsxcv added a commit to frewsxcv/rust that referenced this issue May 2, 2017
Removal pass for anonymous parameters

Removes occurences of anonymous parameters from the
rustc codebase, as they are to be deprecated.

See issue rust-lang#41686 and RFC 1685.

r? @frewsxcv
@matklad
Copy link
Member

matklad commented May 5, 2017

IJR inspection: intellij-rust/intellij-rust#1211

I'll try to add an automatic fix to rustfmt as well. Not sure it's a great idea, but I want to try :)

@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 27, 2017
bors added a commit that referenced this issue Nov 11, 2017
Accept interpolated patterns in trait method parameters

Permit this, basically
```rust
macro_rules! m {
    ($pat: pat) => {
        trait Tr {
            fn f($pat: u8) {}
        }
    }
}
```
it previously caused a parsing error during expansion because trait methods accept only very restricted set of patterns during parsing due to ambiguities caused by [anonymous parameters](#41686), and this set didn't include interpolated patterns.

Some outdated messages from "no patterns allowed" errors are also removed.

Addresses #35203 (comment)
@mark-i-m
Copy link
Member

It doesn't appear that this is linting: https://play.rust-lang.org/?gist=b818c6024acb95add60b339e7708d132&version=nightly

Also, we might want to try to finish this for the 2018 epoch, so we should start linting now

@mark-i-m
Copy link
Member

Oh, duh 🤦‍

It's an allow by default lint.

@mark-i-m
Copy link
Member

Sorry for the multiple rapid posts.

After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:

  • We make the lint warn-by-default as soon as possible
  • We make anon parameters a hard error at the epoch boundary

cc @matklad @est31 @aturon

@SimonSapin
Copy link
Contributor

Should this also apply to fn(Foo) function pointer types?

@matklad
Copy link
Member

matklad commented Feb 18, 2018

@SimonSapin I would say no, because the situation for function pointers is just the opposite: nontrivial patterns are forbidden:

error[E0561]: patterns aren't allowed in function pointer types
 --> main.rs:1:13
  |
1 | type F = fn(&x: &i32);
  |             ^^
 

@mark-i-m
Copy link
Member

Also, I think the original RFC doesn't mention fn pointers...

@petrochenkov
Copy link
Contributor

@SimonSapin
The problem solved by this RFC is unique to trait methods - they may have or not have body, so they may need or not need the full power of patterns in parameters (and full pattern support is incompatible with anonymous parameters).
Function pointers never have body, so they never need non-trivial patterns, so they can freely use anonymous parameters as well.

@vi
Copy link
Contributor

vi commented May 27, 2018

Shall it be addressed before Rust 2018?

Maybe there should be a Github label like "rust-2018-checklist"? Or it should be a Github milestone?

@mark-i-m
Copy link
Member

Do the current plan is to make this warn by default starting at the edition and deprecate it in a later edition. (See #48309)

bors added a commit that referenced this issue May 27, 2018
Make anon params lint warn-by-default

This is intended as a followup on anonymous parameters deprecation.

Cross-posting from #41686:

> After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:
> - We make the lint warn-by-default as soon as possible
> - We make anon parameters a hard error at the epoch boundary

cc @matklad @est31 @aturon
@mark-i-m
Copy link
Member

The OP mentions some adjusting of documentation. Does anyone know specifically which documentation needs to be adjusted?

@cramertj
Copy link
Member

@mark-i-m The forge has a section on updating documentation, but I don't think there's much to do here for deprecations other than to make sure that the book / reference / RBE aren't using the feature.

@Centril
Copy link
Contributor

Centril commented Aug 31, 2018

@cramertj @mark-i-m We should probably note this in the edition guide as well.

@Centril
Copy link
Contributor

Centril commented Sep 15, 2018

Triage: We still need to update the documentation.
ping @mark-i-m

@mark-i-m
Copy link
Member

Sorry for the delay. I have been a bit swamped lately and mostly keeping up from my phone, so not much opportunity to write PRs 😛.

Reference: rust-lang/reference#420
Edition Guide: rust-lang/edition-guide#105

I did a brief search through the nomicon, book, RBE sections on traits and didn't see any other anon params, but please let me know if I missed one.

@steveklabnik
Copy link
Member

Docs have all been merged. This is good to go.

@Centril
Copy link
Contributor

Centril commented Sep 18, 2018

Before we close the tracking issue; we still need to update the reference with notes about the actual edition-breaking change.

@mark-i-m
Copy link
Member

@Centril @steveklabnik I opened rust-lang/reference#421

Does this look like what you were thinking of?

@Centril
Copy link
Contributor

Centril commented Sep 18, 2018

@mark-i-m I was thinking of specifying somewhat more formally (BNF, etc.) but this is good in the interim :)

@mark-i-m
Copy link
Member

@Centril I didn't realize there was a BNF spec of rust anywhere. Could you point me to it so I can update it?

@Centril
Copy link
Contributor

Centril commented Sep 18, 2018

@mark-i-m I don't think there is a BNF spec of Rust anywhere that covers all of Rust and is up to date;

However, we do specify some parts of the language in BNF; for example: https://doc.rust-lang.org/reference/expressions/literal-expr.html.

I think the most up-to-date specification is in parser-lalr.y but it isn't fully updated either.

We don't need to spec it in BNF right now; but as a long term goal it would be good to do so.

@mark-i-m
Copy link
Member

@Centril Perhaps we can spin that off into its own specific issue?

Currently, I think the last piece of documentation that is mandatory for this issue would be rust-lang/reference#421. Right?

@Centril
Copy link
Contributor

Centril commented Sep 21, 2018

@mark-i-m nah; no issue needed; we should define a canonical grammar for Rust at some point, hopefully soon.

Once the reference PR lands we can close this issue.

@Centril
Copy link
Contributor

Centril commented Sep 22, 2018

The reference PR has been merged, so I am closing this.

@Centril Centril closed this as completed Sep 22, 2018
antiguru added a commit to antiguru/differential-dataflow that referenced this issue Jul 2, 2021
From the warning:

anonymous parameters are deprecated and will be removed in the next edition.
this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
for more information, see issue #41686 <rust-lang/rust#41686>


Signed-off-by: Moritz Hoffmann <antiguru@gmail.com>
frankmcsherry pushed a commit to TimelyDataflow/differential-dataflow that referenced this issue Jul 2, 2021
From the warning:

anonymous parameters are deprecated and will be removed in the next edition.
this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
for more information, see issue #41686 <rust-lang/rust#41686>


Signed-off-by: Moritz Hoffmann <antiguru@gmail.com>
fwip pushed a commit to fwip/miniz_oxide that referenced this issue Aug 9, 2021
jqnatividad added a commit to jqnatividad/qsv that referenced this issue Sep 16, 2021
Otherwise we get this and the appveyor build fails:

```
warning: anonymous parameters are deprecated and will be removed in the next edition.
  --> tests\tests.rs:68:18
   |
68 |     fn from_vecs(CsvVecs) -> Self;
   |                  ^^^^^^^ help: try naming the parameter or explicitly ignoring it: `_: CsvVecs`
   |
   = note: `#[warn(anonymous_parameters)]` on by default
   = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
   = note: for more information, see issue #41686 <rust-lang/rust#41686>
error: linking with `i686-w64-mingw32-gcc` failed: exit code: 1
```
github-actions bot pushed a commit to rust-lang/glacier that referenced this issue Dec 4, 2021
=== stdout ===
=== stderr ===
warning: anonymous parameters are deprecated and will be removed in the next edition
  --> <anon>:16:19
   |
16 |     fn parse_mode(&Self, Self::PartialState) {}
   |                   ^^^^^ help: try naming the parameter or explicitly ignoring it: `_: &Self`
   |
   = note: `#[warn(anonymous_parameters)]` on by default
   = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
   = note: for more information, see issue #41686 <rust-lang/rust#41686>

warning: anonymous parameters are deprecated and will be removed in the next edition
  --> <anon>:16:26
   |
16 |     fn parse_mode(&Self, Self::PartialState) {}
   |                          ^^^^^^^^^^^^^^^^^^ help: try naming the parameter or explicitly ignoring it: `_: Self::PartialState`
   |
   = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
   = note: for more information, see issue #41686 <rust-lang/rust#41686>

warning: function is never used: `expr`
  --> <anon>:26:4
   |
26 | fn expr<A>() -> impl Parser
   |    ^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: function is never used: `parse_mode_impl`
  --> <anon>:32:4
   |
32 | fn parse_mode_impl<A>()
   |    ^^^^^^^^^^^^^^^

warning: 4 warnings emitted

==============
freebsd-git pushed a commit to freebsd/freebsd-ports that referenced this issue Dec 12, 2021
Disable CSOUND, same issue as on powerpc64*:
error[E0433]: failed to resolve: use of undeclared crate or module `imp`
  --> /wrkdirs/usr/ports/multimedia/gstreamer1-plugins-rust/work/gst-plugins-rs-d0466b3eee114207f851b37cae0015c0e718f021/cargo-crates/va_list-0.1.3/src/lib.rs:77:15
   |
77 |     internal: imp::VaList,
   |               ^^^ use of undeclared crate or module `imp`

error[E0433]: failed to resolve: use of undeclared crate or module `imp`
  --> /wrkdirs/usr/ports/multimedia/gstreamer1-plugins-rust/work/gst-plugins-rs-d0466b3eee114207f851b37cae0015c0e718f021/cargo-crates/va_list-0.1.3/src/lib.rs:93:24
   |
93 |     unsafe fn get(&mut imp::VaList) -> Self;
   |                        ^^^ use of undeclared crate or module `imp`

warning: anonymous parameters are deprecated and will be removed in the next edition.
  --> /wrkdirs/usr/ports/multimedia/gstreamer1-plugins-rust/work/gst-plugins-rs-d0466b3eee114207f851b37cae0015c0e718f021/cargo-crates/va_list-0.1.3/src/lib.rs:93:19
   |
93 |     unsafe fn get(&mut imp::VaList) -> Self;
   |                   ^^^^^^^^^^^^^^^^ help: try naming the parameter or explicitly ignoring it: `_: &mut imp::VaList`
   |
   = note: `#[warn(anonymous_parameters)]` on by default
   = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
   = note: for more information, see issue #41686 <rust-lang/rust#41686>

For more information about this error, try `rustc --explain E0433`.
warning: `va_list` (lib) generated 1 warning
Error: CliError { error: Some(could not compile `va_list` due to 2 previous errors; 1 warning emitted

Also patch crossbeam-utils crate for no atomics on powerpc.

Building dav1d segfaults, so disable it as well:
    process didn't exit successfully: `/wrkdirs/usr/ports/multimedia/gstreamer1-plugins-rust/work/gst-plugins-rs-d0466b3eee114207f851b37cae0015c0e718f021/_build/target/release/build/dav1d-sys-3a3db191566872b8/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
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-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. 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