Skip to content
Draft
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
80 changes: 80 additions & 0 deletions AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
# AGENTS

Instruction for agents in this project, only to be modified by a human unless instructed otherwise. See https://agents.md.

## Build
```bash
make build # Build the compiler
make clean # Remove build artifacts
make test # Run all tests (unit and integration)
make lint # Run the formatter and linter
```

Use `make test` when fixing bugs or adding new features, `make lint` before committing changes.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I think it makes sense to make it establish baselines before the start to avoid the issues where it thinks there are pre-existing failing tests.
Also I usually start my session with compare this branch to master so that if it's a continuation of an implementation or if it's addressing comments it gathers the context quiker.


Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I would add instructions on how to debug in the project

  • run cargo r -- --help to see options
  • use --ast-lowered and --ast and --ir flags
  • use --check flag..
    I find myself often repeating these instructions

## Code style
1. Do not eagerly add `#[derive(...)]` implementations like a `Debug` or `Clone`. Only add them when needed.
2. Try to keep line lengths at max 110 characters.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

better just run cargo fmt after the edit is done

3. Avoid section and header comments like for example `// -- Types ---------`; use `// Types` instead if it truly makes sense.
4. Define all Rust structs, enums, etc.. first (in logical order) followed by their `impl` blocks in the same order.
```rust
// Bad
enum Foo { ... }
impl Foo { ... }

struct Bar { ... }
impl Bar { ... }

// Good
enum Foo { ... }
struct Bar { ... }

impl Foo { ... }
impl Bar { ... }
```

5. Group statements by logical intent, separated by blank lines. Each group should have a brief comment describing *what* it does so the function reads like an outline — readers can skim the comments top-to-bottom and only dive into the code when they need the *how*. Omit the comment only when the intent is immediately obvious from the code itself. For example
```rust
pub fn source_text(&self, span: Span) -> &str {
let file = self.lookup_source_file(span.lo());

// Convert absolute byte positions to file-relative offsets.
let lo = (span.lo().0 - file.start_pos.0) as usize;
let hi = (span.hi().0 - file.start_pos.0) as usize;

&file.src[lo..hi]
}

pub fn lookup_line_col(&self, pos: BytePos) -> (&str, u32, u32) {
let file = self.lookup_source_file(pos);

// Convert absolute position to file-relative offset.
let relative = RelativeBytePos(pos.0 - file.start_pos.0);

// Binary search for the line containing this position.
let line_idx = file.line_starts.partition_point(|&line| line.0 <= relative.0).saturating_sub(1);

// Offset from the start of that line.
let column_idx = relative.0 - file.line_starts[line_idx].0;

(&file.name, line_idx as u32 + 1, column_idx)
}
```

6. When snapshot testing, prefer inline snapshots.
```rust
// Bad
insta::assert_snapshot!(result);

// Good
insta::assert_snapshot!(result, @r"");
```

7. Avoid fully qualified paths like `plc_source::source_location::SourceLocation` unless required due to name clashes
```
// Bad
fn get_base(node: &AstNode) -> plc_source::source_location::SourceLocation { ... }

// Good
fn get_base(node: &AstNode) -> SourceLocation { ... }
```
17 changes: 17 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
.PHONY: run lint test container

run:
cargo run

check:
cargo check

lint:
cargo fmt --all && cargo clippy --workspace

test:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

should we add skills to let the agent test single lit files?

cargo test --workspace --no-fail-fast && ./scripts/build.sh --lit
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I often notice the agent running the tests twice because first it executes and then sees it's too much output to parse and then add a grep command. Let us also add the instructions to the agent on how to execute tests and see the failures in one go, by either piping the result or saving output files or grepping.


container:
docker build -t rusty-dev .devcontainer/
docker run -it --entrypoint bash -v $(PWD):/workspace -w /workspace rusty-dev
Loading