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

Formatter and parser refactoring #7569

Merged
merged 1 commit into from
Sep 26, 2023
Merged

Conversation

konstin
Copy link
Member

@konstin konstin commented Sep 21, 2023

I got confused and refactored a bit, now the naming should be more consistent. This is the basis for the range formatting work.

Chages:

  • format_module -> format_module_source (format a string)
  • format_node -> format_module_ast (format a program parsed into an AST)
  • Added parse_ok_tokens that takes Token instead of Result<Token>
  • Call the source code source consistently
  • Added a tokens_and_ranges helper
  • python_ast -> module (because that's the type)

@konstin
Copy link
Member Author

konstin commented Sep 21, 2023

Current dependencies on/for this PR:

This comment was auto-generated by Graphite.

@konstin konstin added formatter Related to the formatter internal An internal refactor or improvement labels Sep 21, 2023
Ok(formatted.print()?)
}

pub fn format_node<'a>(
root: &'a Mod,
pub fn format_module_ast<'a>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea here was that you could pass any node eventually (e.g. a single statement)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense for later, but right now e.g. the comments assume that you have the entire AST present anyway

@github-actions
Copy link
Contributor

github-actions bot commented Sep 21, 2023

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

I got confused and refactored a bit
@konstin konstin force-pushed the _formatter-and-parser-refactorings branch from 1aabf59 to dd8b124 Compare September 26, 2023 08:06
@konstin konstin marked this pull request as ready for review September 26, 2023 08:07
@codspeed-hq
Copy link

codspeed-hq bot commented Sep 26, 2023

CodSpeed Performance Report

Merging #7569 will improve performances by 8.46%

Comparing _formatter-and-parser-refactorings (dd8b124) with main (ab64301)

Summary

⚡ 4 improvements
✅ 21 untouched benchmarks

Benchmarks breakdown

Benchmark main _formatter-and-parser-refactorings Change
lexer[pydantic/types.py] 4.1 ms 4 ms +3.69%
lexer[numpy/ctypeslib.py] 2 ms 1.9 ms +2.55%
lexer[unicode/pypinyin.py] 620 µs 592 µs +4.74%
lexer[large/dataset.py] 9.8 ms 9 ms +8.46%

Copy link
Member

@MichaReiser MichaReiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind summarizing your changes? It would make reviewing this PR easier.

@konstin
Copy link
Member Author

konstin commented Sep 26, 2023

updated

@konstin konstin merged commit 4d16e23 into main Sep 26, 2023
@konstin konstin deleted the _formatter-and-parser-refactorings branch September 26, 2023 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatter Related to the formatter internal An internal refactor or improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants