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

rustc_parse top-level cleanups #125815

Merged
merged 14 commits into from
Jun 5, 2024

Conversation

nnethercote
Copy link
Contributor

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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels May 31, 2024
@rustbot
Copy link
Collaborator

rustbot commented May 31, 2024

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@nnethercote
Copy link
Contributor Author

Best reviewed one commit at a time. The commit messages explain each commit.

@rust-log-analyzer

This comment has been minimized.

@nnethercote nnethercote force-pushed the rustc_parse-top-level-cleanups branch from f3eb8ce to b7a73c6 Compare May 31, 2024 12:25
Comment on lines 71 to 72
new_parser_from_file(psess, file, None)
unwrap_or_emit_fatal(new_parser_from_file(psess, file, None))
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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 :)

nnethercote added a commit to nnethercote/rust that referenced this pull request Jun 4, 2024
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>`.
@nnethercote nnethercote force-pushed the rustc_parse-top-level-cleanups branch from b7a73c6 to 3feebde Compare June 4, 2024 00:01
@@ -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
Copy link
Member

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 ...

@spastorino
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 4, 2024

📌 Commit 3feebde has been approved by spastorino

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 4, 2024
…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
@bors
Copy link
Contributor

bors commented Jun 4, 2024

☔ The latest upstream changes (presumably #125989) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 4, 2024
- 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>`.
@nnethercote nnethercote force-pushed the rustc_parse-top-level-cleanups branch from 3feebde to 2d4e7df Compare June 5, 2024 02:44
@nnethercote
Copy link
Contributor Author

I rebased.

@bors r=spastorino

@bors
Copy link
Contributor

bors commented Jun 5, 2024

📌 Commit 2d4e7df has been approved by spastorino

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 5, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2024
…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
@bors bors merged commit 05b4674 into rust-lang:master Jun 5, 2024
6 checks passed
@rustbot rustbot added this to the 1.80.0 milestone Jun 5, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2024
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`
@nnethercote nnethercote deleted the rustc_parse-top-level-cleanups branch June 5, 2024 22:24
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 7, 2024
…ups, r=spastorino

More `rustc_parse` cleanups

Following on from rust-lang#125815.

r? `@spastorino`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jun 7, 2024
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`
lcnr pushed a commit to lcnr/rust that referenced this pull request Jun 12, 2024
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>`.
calebcartwright pushed a commit to calebcartwright/rust that referenced this pull request Jun 22, 2024
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>`.
mattheww added a commit to mattheww/lexeywan that referenced this pull request Sep 10, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants