-
Notifications
You must be signed in to change notification settings - Fork 13.4k
parse: towards unified fn
grammar
#68788
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
babb32e
to
31026e8
Compare
Addressed the comments & squashed into last commit. |
@bors r+ |
📌 Commit 31026e814b2a2b8ba810f1bbe6cd5cb94c369e15 has been approved by |
⌛ Testing commit 31026e814b2a2b8ba810f1bbe6cd5cb94c369e15 with merge f81b49be0be349edc325eedb52330a72a1ce2f77... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
also refactor `FnKind` and `visit_assoc_item` visitors
31026e8
to
ddb9e9b
Compare
Added |
📌 Commit ddb9e9b2525e73baf2e9e5d9d8cfdd32eb9ed628 has been approved by |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
ddb9e9b
to
67c29ed
Compare
On suggesting `#![recursion_limit = "X"]`, note current crate name This would have saved me much confusion e.g. when reading the log output in rust-lang#68788 (comment). r? @estebank
@bors r+ |
📌 Commit 9a4eac3 has been approved by |
…henkov Towards unified `fn` grammar Part of rust-lang#68728. - Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead. - Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns. - We move towards unifying the `fn` front matter; this is fully realized in rust-lang#68728. r? @petrochenkov
Rollup of 9 pull requests Successful merges: - #68691 (Remove `RefCell` usage from `ObligationForest`.) - #68751 (Implement `unused_parens` for `const` and `static` items) - #68788 (Towards unified `fn` grammar) - #68837 (Make associated item collection a query) - #68842 (or_patterns: add regression test for #68785) - #68844 (use def_path_str for missing_debug_impls message) - #68845 (stop using BytePos for computing spans in librustc_parse/parser/mod.rs) - #68869 (clean up E0271 explanation) - #68880 (Forbid using `0` as issue number) Failed merges: r? @ghost
Rustup to rust-lang/rust#68788 cc rust-lang/rust#68901 changelog: none
Rustup to rust-lang/rust#68788 cc rust-lang/rust#68901 changelog: none
late resolve, visit_fn: bail early if there's no body. Fixes rust-lang#69401 which was injected by rust-lang@b2c6eeb in rust-lang#68788. r? @petrochenkov
late resolve, visit_fn: bail early if there's no body. Fixes rust-lang#69401 which was injected by rust-lang@b2c6eeb in rust-lang#68788. r? @petrochenkov
Part of #68728.
Syntactically,
fn
items inextern { ... }
blocks can now have bodies (fn foo() { ... }
as opposed tofn foo();
). As above, we use semantic restrictions instead.Syntactically,
fn
items in free contexts (directly in a file or a module) can now be without bodies (fn foo();
as opposed tofn foo() { ... }
. As above, we use semantic restrictions instead, including for non-ident parameter patterns.We move towards unifying the
fn
front matter; this is fully realized in parse: mergefn
syntax + cleanup item parsing #68728.r? @petrochenkov