-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
rustc_parse
top-level cleanups
#125815
rustc_parse
top-level cleanups
#125815
Conversation
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
Best reviewed one commit at a time. The commit messages explain each commit. |
This comment has been minimized.
This comment has been minimized.
f3eb8ce
to
b7a73c6
Compare
new_parser_from_file(psess, file, None) | ||
unwrap_or_emit_fatal(new_parser_from_file(psess, file, None)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did new_parser_from_file
used to emit a fatal diagnostic? I Haven't looked at any of the changes outside of src/tools/rustfmt
, and just want to make sure we're not changing existing behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. unwrap_or_emit_fatal(new_parser_from_file(...))
is equivalent to the old new_parser_from_file(...)
. So there is no change to existing behaviour.
A nice thing about this is that the catch_unwind
will be removable in a follow-up, removing the asymmetry between the Input::File
and Input::Text
cases here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's great! I appreciate the explanation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had time to do the follow-up, which I added as an extra commit to this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thanks for the updated :)
The `Input::File` and `Input::Text` cases should be very similar. However, currently the `Input::File` case uses `catch_unwind` because, until recently (rust-lang#125815) there was a fallible version of `new_parser_from_source_str` but only an infallible version of `new_parser_from_file`. This difference wasn't fundamental, just an overlooked gap in the API of `rustc_parse`. Both of those operations are now fallible, so the `Input::File` and `Input::Text` cases can made more similar, with no need for `catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to `Vec<Diag>`.
b7a73c6
to
3feebde
Compare
@@ -34,11 +34,6 @@ mod errors; | |||
|
|||
rustc_fluent_macro::fluent_messages! { "../messages.ftl" } | |||
|
|||
// A bunch of utility functions of the form `parse_<thing>_from_<source>` | |||
// where <thing> includes crate, expr, item, stmt, tts, and one that | |||
// uses a HOF to parse anything, and <source> includes file and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I don't know what a "HOF" is.
Higher Order Function. Anyway ...
@bors r+ rollup |
…llaumeGomez Rollup of 11 pull requests Successful merges: - rust-lang#106186 (Add function `core::iter::chain`) - rust-lang#125596 (Convert `proc_macro_back_compat` lint to an unconditional error.) - rust-lang#125696 (Explain differences between `{Once,Lazy}{Cell,Lock}` types) - rust-lang#125917 (Create `run-make` `env_var` and `env_var_os` helpers) - rust-lang#125927 (Ignore `vec_deque_alloc_error::test_shrink_to_unwind` test on non-unwind targets) - rust-lang#125930 (feat(opt-dist): new flag `--benchmark-cargo-config`) - rust-lang#125932 (Fix typo in the docs of `HashMap::raw_entry_mut`) - rust-lang#125933 (Update books) - rust-lang#125944 (Update fuchsia maintainers) - rust-lang#125946 (Include trailing commas in wrapped function declarations [RustDoc]) - rust-lang#125973 (Remove `tests/run-make-fulldeps/pretty-expanded`) Failed merges: - rust-lang#125815 (`rustc_parse` top-level cleanups) r? `@ghost` `@rustbot` modify labels: rollup
☔ The latest upstream changes (presumably #125989) made this pull request unmergeable. Please resolve the merge conflicts. |
- Avoid unnecessary escaping of single quotes within string literals. - Add a missing blank line between two `UNICODE_ARRAY` sections.
Lexing converts source text into a token stream. Parsing converts a token stream into AST fragments. This commit renames several lexing operations that have "parse" in the name. I think these names have been subtly confusing me for years. This is just a `s/parse/lex/` on function names, with one exception: `parse_stream_from_source_str` becomes `source_str_to_stream`, to make it consistent with the existing `source_file_to_stream`. The commit also moves that function's location in the file to be just above `source_file_to_stream`. The commit also cleans up a few comments along the way.
It has a single call site. This also means `CFG_ATTR_{GRAMMAR_HELP,NOTE_REF}` can be moved into `parse_cfg_attr`, now that it's the only function that uses them. And the commit removes the line break in the URL.
Because it takes an `Lrc<SourceFile>`, and for consistency with `source_file_to_stream`.
It's a zero-value wrapper of `Parser::new`.
- Convert it from a macro to a function, which is nicer. - Rename it as `unwrap_or_emit_fatal`, which is clearer. - Fix the comment. In particular, `panictry!` no longer exists. - Remove the unnecessary `use` declaration.
The first one is out-of-date -- there are no longer functions expr, item, stmt. And I don't know what a "HOF" is. The second one doesn't really tell you anything.
…_file`. For consistency with `new_parser_from_{file,source_str}` and `maybe_new_parser_from_source_str`.
It does exactly what is required.
All four functions are simple and have a single call site. This requires making `Parser::parse_inner_attributes` public, which is no big deal.
It's the only one of these functions where `psess` isn't the first argument.
It has a single call site.
Currently we have an awkward mix of fallible and infallible functions: ``` new_parser_from_source_str maybe_new_parser_from_source_str new_parser_from_file (maybe_new_parser_from_file) // missing (new_parser_from_source_file) // missing maybe_new_parser_from_source_file source_str_to_stream maybe_source_file_to_stream ``` We could add the two missing functions, but instead this commit removes of all the infallible ones and renames the fallible ones leaving us with these which are all fallible: ``` new_parser_from_source_str new_parser_from_file new_parser_from_source_file source_str_to_stream source_file_to_stream ``` This requires making `unwrap_or_emit_fatal` public so callers of formerly infallible functions can still work. This does make some of the call sites slightly more verbose, but I think it's worth it for the simpler API. Also, there are two `catch_unwind` calls and one `catch_fatal_errors` call in this diff that become removable thanks this change. (I will do that in a follow-up PR.)
The `Input::File` and `Input::Text` cases should be very similar. However, currently the `Input::File` case uses `catch_unwind` because, until recently (rust-lang#125815) there was a fallible version of `new_parser_from_source_str` but only an infallible version of `new_parser_from_file`. This difference wasn't fundamental, just an overlooked gap in the API of `rustc_parse`. Both of those operations are now fallible, so the `Input::File` and `Input::Text` cases can made more similar, with no need for `catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to `Vec<Diag>`.
3feebde
to
2d4e7df
Compare
I rebased. @bors r=spastorino |
…kingjubilee Rollup of 12 pull requests Successful merges: - rust-lang#123168 (Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude) - rust-lang#125273 (bootstrap: implement new feature `bootstrap-self-test`) - rust-lang#125683 (Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format) - rust-lang#125815 (`rustc_parse` top-level cleanups) - rust-lang#125903 (rustc_span: Inline some hot functions) - rust-lang#125906 (Remove a bunch of redundant args from `report_method_error`) - rust-lang#125920 (Allow static mut definitions with #[linkage]) - rust-lang#125982 (Make deleting on LinkedList aware of the allocator) - rust-lang#125995 (Use inline const blocks to create arrays of `MaybeUninit`.) - rust-lang#125996 (Closures are recursively reachable) - rust-lang#126003 (Add a co-maintainer for the two ARMv4T targets) - rust-lang#126004 (Add another test for hidden types capturing lifetimes that outlive but arent mentioned in substs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#125815 - nnethercote:rustc_parse-top-level-cleanups, r=spastorino `rustc_parse` top-level cleanups A bunch of improvements in and around `compiler/rustc_parse/src/lib.rs`. Many of the changes streamline the API in that file from this (12 functions and one macro): ``` name args return type ---- ---- ----------- panictry_buffer! Result<T, Vec<Diag>> T pub parse_crate_from_file path PResult<Crate> pub parse_crate_attrs_from_file path PResult<AttrVec> pub parse_crate_from_source_str name,src PResult<Crate> pub parse_crate_attrs_from_source_str name,src PResult<AttrVec> pub new_parser_from_source_str name,src Parser pub maybe_new_parser_from_source_str name,src Result<Parser, Vec<Diag>> pub new_parser_from_file path,error_sp Parser maybe_source_file_to_parser srcfile Result<Parser, Vec<Diag>> pub parse_stream_from_source_str name,src,override_sp TokenStream pub source_file_to_stream srcfile,override_sp TokenStream maybe_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>> pub stream_to_parser stream,subparser_name Parser ``` to this: ``` name args return type ---- ---- ----------- unwrap_or_emit_fatal Result<T, Vec<Diag>> T pub new_parser_from_source_str name,src Result<Parser, Vec<Diag>> pub new_parser_from_file path,error_sp Result<Parser, Vec<Diag>> new_parser_from_source_file srcfile Result<Parser, Vec<Diag>> pub source_str_to_stream name,src,override_sp Result<TokenStream, Vec<Diag>> source_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>> ``` I found the old API quite confusing, with lots of similar-sounding function names and no clear structure. I think the new API is much better. r? `@spastorino`
…ups, r=spastorino More `rustc_parse` cleanups Following on from rust-lang#125815. r? `@spastorino`
Rollup merge of rust-lang#126052 - nnethercote:rustc_parse-more-cleanups, r=spastorino More `rustc_parse` cleanups Following on from rust-lang#125815. r? `@spastorino`
The `Input::File` and `Input::Text` cases should be very similar. However, currently the `Input::File` case uses `catch_unwind` because, until recently (rust-lang#125815) there was a fallible version of `new_parser_from_source_str` but only an infallible version of `new_parser_from_file`. This difference wasn't fundamental, just an overlooked gap in the API of `rustc_parse`. Both of those operations are now fallible, so the `Input::File` and `Input::Text` cases can made more similar, with no need for `catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to `Vec<Diag>`.
The `Input::File` and `Input::Text` cases should be very similar. However, currently the `Input::File` case uses `catch_unwind` because, until recently (rust-lang#125815) there was a fallible version of `new_parser_from_source_str` but only an infallible version of `new_parser_from_file`. This difference wasn't fundamental, just an overlooked gap in the API of `rustc_parse`. Both of those operations are now fallible, so the `Input::File` and `Input::Text` cases can made more similar, with no need for `catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to `Vec<Diag>`.
rustc's high-level lexer now provides a public interface returning a TokenStream, so we now use that rather than making a Parser and pulling tokens from it one by one. (And in any case the previous approach no longer works, because Parser::token_spacing is no longer public.) See rust-lang/rust#125815 rust-lang/rust#126052 Other rustc changes: ParseSess now provides a dcx() method rather than a public dcx field. There are new NtIdent and NtLifetime TokenKinds, which AIUI won't appear in token streams created by the lexer.
A bunch of improvements in and around
compiler/rustc_parse/src/lib.rs
. Many of the changes streamline the API in that file from this (12 functions and one macro):to this:
I found the old API quite confusing, with lots of similar-sounding function names and no clear structure. I think the new API is much better.
r? @spastorino