-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
parse: towards unified fn
grammar
#68788
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