Initial implementation of named Fn trait parameters - #158517
Conversation
This comment has been minimized.
This comment has been minimized.
4d2b638 to
858e064
Compare
Fn trait parametersFn trait parameters
|
The parser was modified, potentially altering the grammar of (stable) Rust cc @fmease |
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use Why was this reviewer chosen?The reviewer was selected based on:
|
…ameters, r=JohnTitor Initial implementation of named `Fn` trait parameters This is an initial implementation of the feature `named_fn_trait_parameters`. This implementation is incomplete (and also marked as such) , and needs significant further changes to be implemented correctly. To keep the size of this PR managable, I propose we do this in follow-up PRs. I've added a test that shows the current behaviour, with `FIXME` comments where the test output is currently incorrect. Tracking issue: rust-lang#158499 Accepted RFC: rust-lang/rfcs#3955
Rollup of 6 pull requests Successful merges: - #160529 (Upgrade and deduplicate dependencies) - #158517 (Initial implementation of named `Fn` trait parameters) - #158587 (check if len of array const arg matches the expected len of the type when lowering to valtree) - #160748 (Add regression test for cross-crate assoc const private field leak in rustdoc) - #160708 (remove old update mechanism) - #160768 (Fix autodiff_illegal.rs test)
Rollup of 5 pull requests Successful merges: - #158517 (Initial implementation of named `Fn` trait parameters) - #158587 (check if len of array const arg matches the expected len of the type when lowering to valtree) - #160748 (Add regression test for cross-crate assoc const private field leak in rustdoc) - #160708 (remove old update mechanism) - #160768 (Fix autodiff_illegal.rs test)
Rollup merge of #158517 - JonathanBrouwer:named_fn_trait_parameters, r=JohnTitor Initial implementation of named `Fn` trait parameters This is an initial implementation of the feature `named_fn_trait_parameters`. This implementation is incomplete (and also marked as such) , and needs significant further changes to be implemented correctly. To keep the size of this PR managable, I propose we do this in follow-up PRs. I've added a test that shows the current behaviour, with `FIXME` comments where the test output is currently incorrect. Tracking issue: #158499 Accepted RFC: rust-lang/rfcs#3955
|
Fun bit of trivia: #140671 (comment) |
|
Not the right place to discuss this really but IMHO, self receivers shouldn't be syntactically forbidden in this position (only semantically) since that diverges from every other place that can contain "function parameters" IINM. We intentionally allow self receivers in e.g., function pointer types (CC #68764, rust-lang/reference#2240 (comment)) and free function items. As it stands, it means we reject Similarly, for C-variadics. They should be syntactically allowed, too, IMO. ...Actually, I think I'm going to open an issue. Unifying this would once again simplify the grammar; we shouldn't fight the fact that self-receivers & C-variadics are (meant to be) syntactically valid fn params always. Footnotes
|
|
@JonathanBrouwer @JohnTitor These changes to the parser caused a bug on nightly rustfmt rust-lang/rustfmt#7021. Could you look into it? |
|
I'll take a look sometime in the next few days :) |
This is an initial implementation of the feature
named_fn_trait_parameters.This implementation is incomplete (and also marked as such) , and needs significant further changes to be implemented correctly. To keep the size of this PR managable, I propose we do this in follow-up PRs.
I've added a test that shows the current behaviour, with
FIXMEcomments where the test output is currently incorrect.Tracking issue: #158499
Accepted RFC: rust-lang/rfcs#3955