-
Notifications
You must be signed in to change notification settings - Fork 69
chore: introduce AGENTS.md #1594
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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. | ||
|
|
||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would add instructions on how to debug in the project
|
||
| ## 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. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 { ... } | ||
| ``` | ||
| 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: | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
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 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.