-
Notifications
You must be signed in to change notification settings - Fork 664
Add a basic copilot-instructions.md
.
#1272
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
Conversation
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.
Pull Request Overview
Add a basic copilot-instructions.md to guide contributors on project structure, tooling, and testing workflows.
- Outline source directories (
internal
,_extension
) and primary language/tooling (Go, TypeScript port) - Document build, test, format, lint commands via the
hereby
tool - Describe compiler test conventions, snapshot baselining, and contribution steps
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
The source directories of interest that we have are: | ||
|
||
- `internal` - Contains the compiler and language server code. | ||
- `_extension` - Contains a preview VS Code extension code that integrates with the language server. |
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.
Note the existence of _submodules/TypeScript
; I saw a porting PR fail to notice that
## Compiler Features, Fixes, and Tests | ||
|
||
|
||
When fixing a bug or implementing a new feature, at least one minimal test case should always be added in advance to verify the fix. |
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 don’t think this is true at this stage of development. Many things are adequately tested but have existing diffs that should be deleted. Even for fixes outside porting PRs, I would rather not add new tests that are wholly duplicative.
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.
How would I phrase this exactly?
Don't add a test case, unless nothing changes, in which case, undo all your work, add a failing test case, and re-apply the changes you've made and verify that they fix the issue.
I kind of doubt that a bot is going to do the right thing, so I'd rather just say "delete the new test and accept baselines". But honestly, I'm flexible here.
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 guess it’s not bad if the effect is a new correct test that we can take or leave, but I think the diff system does need to be explained, as deleting diffs is a more reliable sign that the implementation is right than the AI’s judgment of new baselines that go with an AI-written test case.
Add a basic `copilot-instructions.md`. (microsoft#1272)
See more here.