Skip to content

Restructure phase documentation#423

Open
vinistock wants to merge 1 commit intomainfrom
01-08-restructure_phase_documentation
Open

Restructure phase documentation#423
vinistock wants to merge 1 commit intomainfrom
01-08-restructure_phase_documentation

Conversation

@vinistock
Copy link
Member

@vinistock vinistock commented Jan 8, 2026

This PR does 3 things:

  • Restructures our architecture doc to split phase documentation into their own files
  • Documents the resolution phase design
  • Updates our graph image to match the current state

I made a few conceptual name changes:

  • Indexing -> Extraction (instead of discovery). Based on the discussion on Stan's PR
  • Extraction + Resolution -> Indexing

I believe that makes it a bit clearer. We have indexing as a "stage" combining two phases. Let me know what you think!

Copy link
Member Author

vinistock commented Jan 8, 2026

This stack of pull requests is managed by Graphite. Learn more about stacking.

@vinistock vinistock self-assigned this Jan 8, 2026
@vinistock vinistock added the documentation Improvements or additions to documentation label Jan 8, 2026 — with Graphite App
@vinistock vinistock marked this pull request as ready for review January 8, 2026 20:56
@vinistock vinistock requested a review from a team as a code owner January 8, 2026 20:56
Copy link
Contributor

Choose a reason for hiding this comment

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

I think Declaration should be declined into Class, Module, etc.

Comment on lines +9 to +11
A **Definition** represents a single source-level construct found at a specific location in the code. It captures key
information from the AST without making major transformations or assumptions about runtime behavior. Definitions are
captured during extraction.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I understand the last, are we talking about indexing?

Suggested change
A **Definition** represents a single source-level construct found at a specific location in the code. It captures key
information from the AST without making major transformations or assumptions about runtime behavior. Definitions are
captured during extraction.
A **Definition** represents a single source-level construct found at a specific location in the code. It captures key
information from the AST without making major transformations or assumptions about runtime behavior. Definitions are
captured during indexing.

```

**Definitions** (4 total - what the indexer discovers):
**Definitions** (4 total - what extraction discovers):
Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, it looks like we're renaming the second phase.

What if we named the phases after what they creates? 🤔

  1. listing becomes documents, or maybe uris or paths
  2. indexer becomes definitions
  3. resolution becomes declarations

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm honestly not a fan. I'd stick with names that try to describe the phase rather than just use its outputs.

@@ -0,0 +1,49 @@
# Extraction
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather have one long file than a few short ones. It makes it easier to search.

clarify at the goal of the steps.

- Indexing: stage for building the knowledge about the codebase
- Phase 1: [Extraction](extraction.md)
Copy link
Contributor

Choose a reason for hiding this comment

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

There is a phase before were we collect all the files we'll index

@@ -0,0 +1,49 @@
# Extraction

During extraction, source code is parsed into ASTs and key information is recorded to be transformed and used in
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we actually do any "transformation"?

semantics.

The intention is to be able to work backwards to the original code since the goal is to support many different tools.
As an example, considering an `unless` as an `if !` is generally correct for static analysis. However, it would not be
Copy link
Contributor

Choose a reason for hiding this comment

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

This may be confusing as we do not even look at method bodies.

What if we used the example of storing attributes as methods?


- Creates `Definition` objects for classes, modules, methods, constants, variables
- Records source locations, comments, and lexical ownership (`owner_id`)
- Captures unresolved constant references (e.g., `Foo::Bar` as a `NameId`)
Copy link
Contributor

Choose a reason for hiding this comment

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

And also unresolved method references


Trying to create a tree of dependencies ahead of time to resolve constants is difficult because some dependencies are
only identified when we are in the middle of performing resolution. Instead of taking that approach, the resolution
loop is an optimistically sorted worklist algorithm (inspired by [Sorbet's](https://github.com/sorbet/sorbet) approach).
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's point to the exact file for reference

where we go through the list of work. If we exhaust the worklist or fail to make any progress in a pass, then we
finalize the loop.

```rust
Copy link
Contributor

Choose a reason for hiding this comment

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

At some point a diagram with boxes and arrows may be easier to follow. But let's leave this for later once everything stabilized.

@vinistock vinistock force-pushed the 01-08-restructure_phase_documentation branch from 45b07fd to 148598c Compare January 9, 2026 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants