-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add sample launch.json
config for debugging a Prism test
#195
base: prism
Are you sure you want to change the base?
Conversation
Instead of listing all the `srcs` and `hdrs` for the Prism C library, use a glob to pull all `.c` and `.h` files, excluding the ones that are generated by the genrule so that we can specify that the library depends on that genrule without listing those files twice.
…et or prism If `--parser=prism`, diverge in the `pipeline.cc` file and run a separate method that parses the source with prism.
This involves setting up a `convertPrismToSorbet` method that checks against every possible node type. Program and Statements are basically skipped because Sorbet doesn't use them, and then Integer is converted from a prism node to a Sorbet node. Co-authored-by: Vinicius Stock <[email protected]>
1. Add a new test suite that only tests files in the `test/prism_regression` folder 2. Modify Sorbet's test code to allow the user to specify a parser 3. Add logic to the pipeline test runner to call `runPrismParser` when specified
Sorbet constructs slightly different ASTs depending on whether a program contains one statement or more than one statements. Correctly parsing programs with more than one statement will make it easier to benchmark this project.
In order to compare the performance of Prism with the Sorbet parser, we need to be able to stop AST generation after Prism has run and before we translate the Prism AST into the Sorbet AST.
These benchmarks will help us measure the progress of the prism in Sorbet project. While they can be run from any machine, for "official" results, they should be run on an AWS bare metal instance. Results should be added to the prism_benchmarks/data directory.
Relocate it to the `PM_STATEMENTS_NODE` case so it can be reused by multiple parent nodes.
…pt-args Forward `build_compilation_db.sh` args to its Bazel build command
Use a string literal as the default fallback
Implement Prism -> Sorbet translation for `Hash` literals
Implement Prism -> Sorbet translation for method calls
Tidy up our null checks
Fix Prism builds when not using `--config=dbg`
"stopOnEntry": false, | ||
"sourceMap": { | ||
// `bazel info execution_root` to get this path: | ||
"/private/var/tmp/_bazel_alex/6cfcf34b544626b5ce95e8aa2935011b/execroot/com_stripe_ruby_typer": "${workspaceFolder}", |
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 haven't figured out how to automatically set this by calling bzel info execution_root
yet 🤔
"name": "Debug Prism test in LLDB", | ||
"program": "${workspaceFolder}/bazel-out/darwin-dbg/bin/test/test_PosTests/prism_regression/false.runfiles/com_stripe_ruby_typer/test/pipeline_test_runner", | ||
"args": [ | ||
"--single_test=com_stripe_ruby_typer/test/prism_regression/false.rb", |
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.
It would be nice to have a drop-down that lets you pick an unit test in that directory, but I couldn't find an easy way to do that 😅
"--define", | ||
"RUBY_PATH='/opt/rubies/3.3.4/'", |
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.
Workaround until we figure out how to set this from the build configs themselves
Motivation
Enable building a target from the Bazel VSCode extension:
Add a sample
launch.json
for visually debugging a Prism unit test: