Skip to content

Minor fixes to compiler procedures #5

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

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions _overviews/scala3-contribution/procedures-inspection.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,6 +65,14 @@ definitions introduced by the `source` argument.

Each one of `typeStrings` is then printed, displaying their internal structure, alongside their class.

## Debugging tree creation site

Sometimes you encounter a tree in the compiler and you'd like to know where that tree was created. To do so:

1. Run the compiler with the `-Xprint:<phase-name>` flag (discussed above) to get the tree in question output and the `-Yshow-tree-ids` flag. The `-Yshow-tree-ids` flag will show the ids of all the trees when printing them. You'll see something like `println#223("Hello World"#37)`.
2. Find the id of the desired tree.
3. Run the compiler with `-Ydebug-tree-with-id <tree-id>` flag. The compiler will print a stack trace pointing to the creation site of the tree with a given id.

### Examples

Here, given a previously defined `class Box { type X }`, we inspect the return type `Box#X`:
Expand Down
2 changes: 2 additions & 0 deletions _overviews/scala3-contribution/procedures-intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,8 @@ previous-page: start-intro
next-page: procedures-cheatsheet
---

This chapter introduces instructions on how to do basic tasks when fixing compiler issues. The tasks include how to reproduce an issue, how to navigate to where the issue manifests itself in the compiler, how to inspect various values encountered in the compiler and how to create a test for your fix. You can find the instructions of how to do the above in the following sections.

[Reproduce the issue][2]

[Navigation][3]
Expand Down
10 changes: 9 additions & 1 deletion _overviews/scala3-contribution/procedures-reproduce.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,8 +25,16 @@ The procedure of reproducing an issue with dotty-issue-workspace installed (see

#### Basic

The most basic usage for the `launch.iss` is as follows:
Say you want to reproduce locally issue [#7710](https://github.com/lampepfl/dotty/issues/7710). To do so:

1. Follow [steps in README](https://github.com/anatoliykmetyuk/dotty-issue-workspace#getting-started) to install the plugin
2. In your Issue Workspace folder (as defined in the plugin's README file, "Getting Started" section, step 2), create a subfolder for the issue: `mkdir i7710`
3. Create a file with the reproduction: `cd i7710; touch Test.scala`. In that file, insert the code from the issue.
4. Create a file `launch.iss` with the following content: `scala3/scalac $here/Test.scala`
5. Open sbt console in the Dotty main repo. If you still don't have the Dotty repo cloned locally, run `git clone <https://github.com/lampepfl/dotty.git`>
6. From sbt console opened in the Dotty repo, run `issue i7710` to reproduce the issue

The most basic usage for the `launch.iss` demonstrated above is as follows:
```bash
scala3/scalac $here/Test.scala
```
Expand Down