mirror of
https://github.com/vczh-libraries/Release.git
synced 2026-08-20 22:07:26 +08:00
Sync copilot agent customization files via copilotInitAll.ps1.
This commit is contained in:
vczh
@@ -1,33 +1,38 @@
|
||||
# Building a Solution
|
||||
|
||||
- Go to `Windows Specific` section if you are on Windows.
|
||||
- Go to `Linux Specific` section if you are on Linux or macOS.
|
||||
|
||||
## Windows Specific
|
||||
|
||||
- Only run `copilotBuild.ps1` to build a solution.
|
||||
- DO NOT use msbuild by yourself.
|
||||
- The script builds all projects in a solution.
|
||||
|
||||
## Executing copilotBuild.ps1
|
||||
### Executing copilotBuild.ps1
|
||||
|
||||
Before building, ensure the debugger has stopped.
|
||||
If there is any error message, it means the debugger is not alive, it is good.
|
||||
|
||||
```
|
||||
& REPO-ROOT\.github\Scripts\copilotDebug_Stop.ps1
|
||||
```
|
||||
|
||||
And then run this script to build the solution:
|
||||
Run this script to build the solution:
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\Scripts\copilotBuild.ps1
|
||||
```
|
||||
|
||||
## Ensure Target Configuration
|
||||
It is possible that, before running `copilotBuild.ps1`, the binary to compile is still running or still being debugged. This could cause the linking to fail. You need to check the error message, and in case when it happens:
|
||||
- Kill `cdb` process first, if there is any.
|
||||
- The cdb path is stored in `$env:CDBPATH`.
|
||||
- Avoid running `copilotDebug_Stop.ps1` directly.
|
||||
- Kill the binary process that is blocked.
|
||||
- Rebuild, and this issue should gone.
|
||||
|
||||
### Ensure Target Configuration
|
||||
|
||||
`-Configuration` and `-Platform` arguments are available to specify the target configuration:
|
||||
- `-Configuration` could be `Debug` (default) or `Release`.
|
||||
- `-Platform` could be `x64` (default) or `Win32`
|
||||
- Pick the default option (omit both arguments) when there is no specific requirements.
|
||||
|
||||
## The Correct Way to Read Compiler Result
|
||||
### The Correct Way to Read Compiler Result
|
||||
|
||||
- The only source of trust is the raw output of the compiler.
|
||||
- Wait for the script to finish before reading the log file.
|
||||
@@ -40,3 +45,18 @@ cd SOLUTION-ROOT
|
||||
- "0 Warning(s)"
|
||||
- "0 Error(s)"
|
||||
- DO NOT delete the log file by yourself.
|
||||
|
||||
## Linux Specific
|
||||
|
||||
Building only happens on a folder that has a `vmake` file.
|
||||
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
|
||||
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
|
||||
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
|
||||
You are required to `cd` to such folder before running `build.sh`, otherwise it will fail.
|
||||
|
||||
Call `REPO-ROOT/.github/Ubuntu/build.sh` for incremental build.
|
||||
Call `REPO-ROOT/.github/Ubuntu/build.sh -f` for full rebuild.
|
||||
`build.sh` will read the local `vmake` configuration file and generate a `makefile` in the same folder before building.
|
||||
`build.sh` will also run other script files in that folder, run `chmod +x` if any script file is blocked.
|
||||
|
||||
Only the "debug x64" configuration is supported on Linux. If you are instructed to build and run other configuration, ignore it.
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
## Debugging a Project
|
||||
# Debugging a Project
|
||||
|
||||
- Go to `Windows Specific` section if you are on Windows.
|
||||
- Go to `Linux Specific` section if you are on Linux or macOS.
|
||||
|
||||
## Windows Specific
|
||||
|
||||
Debugging would be useful when you lack necessary information.
|
||||
In this section I offer you a set of PowerShell scripts that work with CDB (Microsoft's Console Debugger).
|
||||
@@ -15,6 +20,8 @@ cd SOLUTION-ROOT
|
||||
start powershell {& REPO-ROOT\.github\Scripts\copilotDebug_Start.ps1 -Executable PROJECT-NAME}
|
||||
```
|
||||
|
||||
If the debugger is already started, this script will fail because the pipe name is occupied. That probably means the last time you forgot to stop the debugger. You can kill `cdb` and the process being debugged, before starting a new debugger.
|
||||
|
||||
The `start powershell {}` is necessary; otherwise the script will block the execution forever causing you to wait infinitely.
|
||||
The script will finish immediately, leaving a debugger running in the background. You can send commands to the debugger.
|
||||
The process being debugged is paused at the beginning, you are given a chance to set breakpoints.
|
||||
@@ -32,6 +39,14 @@ This script is also required to run before compiling only when Visual Studio Cod
|
||||
|
||||
If there is any error message, it means the debugger is not alive, it is good.
|
||||
|
||||
#### Warning
|
||||
|
||||
You should never combine `copilotDebug_Stop.ps1` with others in one single powershell call.
|
||||
It could block you forever if some system thing went wrong.
|
||||
You should run this script separately, and do not just wait for its input.
|
||||
The script is supposed to be done very fast, you should keep reading the terminal output parallelly.
|
||||
And when it seems to never finish, kill the terminal and cdb directly.
|
||||
|
||||
### Sending Commands to Debugger
|
||||
|
||||
```
|
||||
@@ -69,3 +84,34 @@ You can also use `dv -rX` to expand "X" levels of fields, the default option is
|
||||
- Only use **dv** without any parameters.
|
||||
- DO NOT use **dt**.
|
||||
- DO NOT use **q**, **qd**, **qq**, **qqd** etc to stop the debugger, always use `copilotDebug_Stop.ps1`.
|
||||
|
||||
## Linux Specific
|
||||
|
||||
Like building and running, debugging must be performed from the same folder that contains `vmake`:
|
||||
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
|
||||
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
|
||||
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
|
||||
You are required to `cd` to such folder before launching `lldb`, otherwise relative paths to the binary and source files will be wrong.
|
||||
|
||||
`lldb` is going to block the terminal and wait for interaction, you should always start `lldb` in a PTY-backed tool session, for example:
|
||||
|
||||
```bash
|
||||
lldb -- ./Bin/UnitTest /C
|
||||
```
|
||||
|
||||
Keep the session id returned by the tool. Send debugger commands as newline-terminated stdin, one round at a time, and wait for output between rounds.
|
||||
|
||||
End the session with:
|
||||
|
||||
```text
|
||||
quit
|
||||
```
|
||||
|
||||
If the debugged process is still running or stuck, send Ctrl-C (`\u0003`), then send:
|
||||
|
||||
```text
|
||||
process kill
|
||||
quit
|
||||
```
|
||||
|
||||
For non-interactive one-shot debugging, wrap `lldb` with `timeout` so it cannot block forever.
|
||||
|
||||
@@ -1,20 +1,17 @@
|
||||
# Running a CLI Application Project
|
||||
|
||||
- Go to `Windows Specific` section if you are on Windows.
|
||||
- Go to `Linux Specific` section if you are on Linux or macOS.
|
||||
|
||||
## Windows Specific
|
||||
|
||||
- Only run `copilotExecute.ps1` to run a unit test project.
|
||||
- DO NOT call executables or scripts yourself.
|
||||
|
||||
## Executing copilotExecute.ps1
|
||||
### Executing copilotExecute.ps1
|
||||
|
||||
`PROJECT-NAME` is the name of the project.
|
||||
|
||||
Before testing, ensure the debugger has stopped.
|
||||
If there is any error message, it means the debugger is not alive, it is good.
|
||||
|
||||
```
|
||||
& REPO-ROOT\.github\Scripts\copilotDebug_Stop.ps1
|
||||
```
|
||||
|
||||
And then run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
|
||||
Run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
@@ -29,3 +26,20 @@ cd SOLUTION-ROOT
|
||||
- `-Configuration` could be `Debug` (default) or `Release`.
|
||||
- `-Platform` could be `x64` (default) or `Win32`
|
||||
- Pick the default option (omit both arguments) when there is no specific requirements.
|
||||
|
||||
## Linux Specific
|
||||
|
||||
Building only happens on a folder that has a `vmake` file.
|
||||
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
|
||||
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
|
||||
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
|
||||
You are required to `cd` to such folder before running the compiled CLI binary, otherwise it will fail.
|
||||
|
||||
After a successful build, `Bin/UnitTest` will be generated as the executable.
|
||||
If you can'f find it, first check if the build succeeded, and then read `makefile` to find the correct binary file name.
|
||||
|
||||
**IMPORTANT**: Always run it async, read terminal output and its return code.
|
||||
Compiled binary might have bug causing it to trap in a dead looping. DO NOT just wait for it to complete.
|
||||
If you feel suspicious, you are recommended to kill the process and run it again with the debugger.
|
||||
|
||||
Only the "debug x64" configuration is supported on Linux. If you are instructed to build and run other configuration, ignore it.
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
# Running a GacUI Application Project
|
||||
|
||||
- Go to `Windows Specific` section if you are on Windows.
|
||||
- Go to `Linux Specific` section if you are on Linux or macOS.
|
||||
|
||||
## Windows Specific
|
||||
|
||||
(to edit ...)
|
||||
|
||||
## Linux Specific
|
||||
|
||||
NOT SUPPORTED
|
||||
|
||||
@@ -1,20 +1,17 @@
|
||||
# Running a Unit Test Project
|
||||
|
||||
- Go to `Windows Specific` section if you are on Windows.
|
||||
- Go to `Linux Specific` section if you are on Linux or macOS.
|
||||
|
||||
## Windows Specific
|
||||
|
||||
- Only run `copilotExecute.ps1` to run a unit test project.
|
||||
- DO NOT call executables or scripts yourself.
|
||||
|
||||
## Executing copilotExecute.ps1
|
||||
### Executing copilotExecute.ps1
|
||||
|
||||
`PROJECT-NAME` is the name of the project.
|
||||
|
||||
Before testing, ensure the debugger has stopped.
|
||||
If there is any error message, it means the debugger is not alive, it is good.
|
||||
|
||||
```
|
||||
& REPO-ROOT\.github\Scripts\copilotDebug_Stop.ps1
|
||||
```
|
||||
|
||||
And then run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
|
||||
Run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
@@ -30,7 +27,7 @@ cd SOLUTION-ROOT
|
||||
- `-Platform` could be `x64` (default) or `Win32`
|
||||
- Pick the default option (omit both arguments) when there is no specific requirements.
|
||||
|
||||
## Ensure Expected Test Files are Selected
|
||||
### Ensure Expected Test Files are Selected
|
||||
|
||||
Test cases are organized in multiple test files.
|
||||
In `PROJECT-NAME\PROJECT-NAME.vcxproj.user` there is a filter, when it is effective, you will see filtered test files marked with `[SKIPPED]` in `Execute.log`.
|
||||
@@ -52,7 +49,7 @@ DO NOT delete this `*.vcxproj.user` file.
|
||||
DO NOT clean the filter (aka delete all `/FILE-NAME.cpp`) by yourself. I put a filter there because running everything is slow and unnecessary for the current task.
|
||||
Ignore `LocalDebuggerCommandArgumentsHistory` in `*.vcxproj.user`.
|
||||
|
||||
## The Correct Way to Read Test Result
|
||||
### The Correct Way to Read Test Result
|
||||
|
||||
- The only source of trust is the raw output of the unit test process.
|
||||
- Wait for the script to finish before reading the log file.
|
||||
@@ -68,3 +65,29 @@ Ignore `LocalDebuggerCommandArgumentsHistory` in `*.vcxproj.user`.
|
||||
- "Passed test files: X/X"
|
||||
- "Passed test cases: Y/Y"
|
||||
- DO NOT delete the log file by yourself.
|
||||
|
||||
## Linux Specific
|
||||
|
||||
Building only happens on a folder that has a `vmake` file.
|
||||
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
|
||||
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
|
||||
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
|
||||
You are required to `cd` to such folder before running the compiled unit test binary, otherwise it will fail.
|
||||
|
||||
After a successful build, `Bin/UnitTest` will be generated as the executable.
|
||||
If you can'f find it, first check if the build succeeded, and then read `makefile` to find the correct binary file name.
|
||||
The unit test project supports following command line options:
|
||||
- `/D`: crash at the first failure, the error message is not printed. This is recommended for debugging.
|
||||
- `/C`: crash at the first failure and print the error message if possible. This is recommended for usual running.
|
||||
- `/R`: print all failures without crashing. Be careful to use it because failure cases usually affect following cases, making everything not stable after the first failure.
|
||||
- `/F:FILENAME.cpp`: file filter.
|
||||
- If no `/F` appears, all test cpp files will run.
|
||||
- If one or multiple `/F` appear, only specified cpp files will run.
|
||||
- `FILENAME.cpp` do not contain file path, and it is case sensitive.
|
||||
|
||||
**IMPORTANT**: Always run it async, read terminal output and its return code.
|
||||
Compiled binary might have bug causing it to trap in a dead looping. DO NOT just wait for it to complete.
|
||||
If you feel suspicious, you are recommended to kill the process and run it again with the debugger.
|
||||
When `/D` or `/C` is specified, the unit test binary stops at the first failure, causing it not able to summary how many test cases pass or fail at the end. This would be an obvious signal to tell that it fails.
|
||||
|
||||
Only the "debug x64" configuration is supported on Linux. If you are instructed to build and run other configuration, ignore it.
|
||||
|
||||
@@ -6,33 +6,30 @@
|
||||
- Following `Leveraging the Knowledge Base`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
- Before writing to a source file, read it again and make sure you respect my parallel editing.
|
||||
- If any `*.prompt.md` file is referenced, take immediate action following the instructions in that file.
|
||||
- **DO NOT ASK ANY QUESTION** if you are not explicitly instructed to make questions. Run the user's task to the end.
|
||||
- The only exception will be there are serious conflict information in user's task. This is rare, try your best effort to resolve the ambiguity by yourself, and only ask when you are totally stuck.
|
||||
|
||||
## External Tools Environment and Context
|
||||
## (Windows Specific) External Tools Environment and Context
|
||||
|
||||
- If you are on Windows OS:
|
||||
- Always prefer the offered script files instead of direct CLI commands.
|
||||
- DO NOT call `msbuild` or other executable files directly.
|
||||
- DO NOT create or delete any file unless explicitly directed.
|
||||
- MUST run any PowerShell script in this format: `& absolute-path.ps1 parameters...`.
|
||||
- Multiple powershell commands are concatenated with `;` to be executed in one line.
|
||||
- Always prefer the offered script files instead of direct CLI commands.
|
||||
- DO NOT call `msbuild` or other executable files directly.
|
||||
- DO NOT create or delete any file unless explicitly directed.
|
||||
- MUST run any PowerShell script in this format: `& absolute-path.ps1 parameters...`.
|
||||
- Multiple powershell commands are concatenated with `;` to be executed in one line.
|
||||
|
||||
- If you are on Linux, offered powershell script files won't work and here are replacements:
|
||||
- You still need to maintain `*.sln`, `*.slnx`, `*.vcxitems`, `*.vcxproj`, `*.vcxproj.filters`.
|
||||
- DO NOT call `cmake` (as cmake is not in use), `make`, `clang++`, `g++`.
|
||||
- DO NOT call `gdb` or `lldb` unless you can interact with it, otherwise a running debugger will cause subsequent building to fail.
|
||||
- All `makefile` files are generated out of these solution and project files.
|
||||
- All `vmake` files are in `REPO-ROOT/Test/Linux` or its sub folders.
|
||||
- If `vmake` is directly in that folder, that is the only project you can and need to work on.
|
||||
- Otherwise, any important `*.vcxproj` will have a corresponding folder containing the `vmake` for that project.
|
||||
- DO NOT modify `makefile` as they will be re-generated and your modification will be lost. Modify `vmake` instead. In `vmake` you can:
|
||||
- Add a `*.vcxitems` or `*.vcxproj` project to add every file they use
|
||||
- Remove C++ source files added from projects that only work for Windows
|
||||
- Add new C++ source files for Linux replacement, etc.
|
||||
- All following commands should run in the folder containing the `vmake` file:
|
||||
- `vmake --make` to generate `makefile` according to the latest content in solution and project files.
|
||||
- `vbuild --build` to incrementally build the project.
|
||||
- `vbuild --full-build` to fully rebuild the project.
|
||||
- An executable file `./Bin/UnitTest` is generated after a successful `vbuild`.
|
||||
## (Linux Specific) External Tools Environment and Context
|
||||
|
||||
- DO NOT run any powershell script file as they are for Windows only.
|
||||
- The bash script `REPO-ROOT/.github/Ubuntu/build.sh` is the only script you should call for building any project. `build.sh` will also run other script files in that folder, run `chmod +x` if any script file is blocked.
|
||||
- `build.sh` is usable in `REPO-ROOT/Test/Linux` or `REPO-ROOT/Test/Linux/PROJECT-NAME`. It reads the local `vmake` configuration file, generates a `makefile`, and builds it.
|
||||
- Call `build.sh -f` for full rebuild.
|
||||
- Call `build.sh` for incremental build.
|
||||
- `vmake`, `vmake.txt` and `makefile` all live in the same `Test/Linux` (or `Test/Linux/PROJECT-NAME`) folder:
|
||||
- `vmake` is the configuration file derived from MSBuild project files. When the source file list changes, the MSBuild project files are expected to be modified, and `build.sh` will regenerate the rest.
|
||||
- `vmake.txt` and `makefile` are generated files, you are not allowed to modify them.
|
||||
- Unlike offered powershell scripts, `build.sh` does not produce `Build.log` or equivalent log file, running unit test does not produce `Execute.log` or equivalent log file.
|
||||
- Always use `lldb` and other interactable tools in PTY-backed tool session.
|
||||
- DO NOT call `cmake`, `make`, `clang++`, `g++`, `gdb` directly. `build.sh` and `lldb` are for building and debugging.
|
||||
|
||||
## Coding Guidelines and Tools
|
||||
|
||||
@@ -78,7 +75,7 @@ If you need to find any document for the current working task, they are in the `
|
||||
- If it is defined in the standard C++ library or third-party library, use the full name.
|
||||
- If it is defined in the source code, use the full name if there is ambiguity, and then mention the file containing its definition.
|
||||
|
||||
## Accessing Script Files
|
||||
## (Windows Specific) Accessing Script Files
|
||||
|
||||
If you need to find any script or log files, they are in the `REPO-ROOT/.github/Scripts` folder:
|
||||
- `copilotPrepare.ps1`
|
||||
@@ -91,6 +88,11 @@ If you need to find any script or log files, they are in the `REPO-ROOT/.github/
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
## (Linux Specific) Accessing Script Files
|
||||
|
||||
If you need to find any script files, they are in the `REPO-ROOT/.github/Ubuntu` folder:
|
||||
- `build.sh`
|
||||
|
||||
## Writing C++ Code
|
||||
|
||||
- This project uses C++ 20, you are recommended to use new C++ 20 feature aggressively.
|
||||
@@ -104,12 +106,21 @@ If you need to find any script or log files, they are in the `REPO-ROOT/.github/
|
||||
- The project only uses a very minimal subset of the standard library. I have substitutions for most of the STL constructions. Always use mine if possible:
|
||||
- Always use `vint` instead of `int`.
|
||||
- Always use `L'x'`, `L"x"`, `wchar_t`, `const wchar_t` and `vl::WString`, instead of `std::string` or `std::wstring`.
|
||||
- Always use `FilePath` for file path operations.
|
||||
- Use my own collection types vl::collections::* instead of std::*
|
||||
- Regular expression utilities are offered by `vl::regex::Regex`, here are important syntax differences with other regular expression implementation:
|
||||
- "." means the dot character, "/." or "\." (or "\\." in C++ string literal) means any character.
|
||||
- Both "/" and "\" escape characters, you are recommended to use "/" in C++ string literals.
|
||||
- Therefore you need "//" for the "/" character and "/\\" or "/\\\\" for the "\" character in C++ string literals.
|
||||
- Constructing a `Regex` object is expensive. If a regular expression is used multiple times or multiple places, make a variable to reuse it, but it should not be a global variable.
|
||||
- Check out `REPO-ROOT/.github/KnowledgeBase/Index.md` for more information of how to choose correct C++ data types.
|
||||
- Rules for expression inavailability of values:
|
||||
- If any number is expected to be valid only when non-negative, you could use `-1` to represent invalid value.
|
||||
- If an object is expected to be valid only when non-null, you could use `nullptr` on `T*` or `Ptr<T>` to represent invalid value.
|
||||
- Use `Nullable<T>` to represent any invalid value if possible.
|
||||
- DO NOT use `Nullable<T*>`, `Nullable<Ptr<T>>` or `Nullable<Nullable<T>>`, this is too confusing.
|
||||
- Only when there is no other choice, use an extra `bool` variable.
|
||||
- This could happen when "null" semantic is valid.
|
||||
- Rules for C++ header files:
|
||||
- Guard them with macros instead of `#pragma once`.
|
||||
- In a class/struct/union declaration, member names must be aligned in the same column at least in the same public, protected or private section.
|
||||
@@ -120,6 +131,32 @@ If you need to find any script or log files, they are in the `REPO-ROOT/.github/
|
||||
- Use `using namespace` statement if necessary to prevent from repeating namespace everywhere.
|
||||
- `vl::stream::` is an exception, always use `stream::` with `using namespace vl;`, DO NOT use `using namespace vl::stream;`.
|
||||
|
||||
### Advanced C++ Coding Rules
|
||||
|
||||
- DO NOT make helper functions that only used once, especially it is only called in one destructor.
|
||||
- When generating Workflow script, avoid building text, you should always build the AST. The AST type for a complete Workflow script module is `WfModule`.
|
||||
|
||||
You are always recommended to debug the compiled binary if you find it difficult to figure out what is going on, or after several failed attemps of "read and guess".
|
||||
|
||||
### Advanced C++ Coding Rules for Reflectable Types
|
||||
|
||||
- DO NOT make global variables with types that carry constructors or destructors, even when they are implicit.
|
||||
- This could mess up the order of initialization, finalization or memory leak detector.
|
||||
- One exception will be `WString` which is initialized using `WString::Unmanaged`, such constructor and destructor does not do memory management.
|
||||
- Another exception will be `Pair`, `Nullable` or `Tuple` with valid types here.
|
||||
- If pointers are needed, you could only use `T*` and do initialization or finalization explicitly. All such objects should be destroyed in `main`, `wmain`, `WinMain` or `GuiMain`, before memory leak detector runs.
|
||||
- Prefer latest C++ features (up to C++ 20).
|
||||
- Prefer template variadic arguments, over hard-coded-counting solutions.
|
||||
- Any interface or class `X` should inherit from `vl::reflection::Description<X>`.
|
||||
- If such class (not including interface) should be inheritable in Workflow script, use `AggregatableDescription` instead of `Description`.
|
||||
- No `const` is allowed for methods or reference types.
|
||||
- Prefer `IValue*` interfaces for container types on interfaces.
|
||||
- Container types and some other types supports range-based for loop. Always prefer range-based for loop over other loops.
|
||||
- You can used `indexed(container)` to convert a container of type `T` to `Pair<T, vint>`, to read the corrent index.
|
||||
- Avoid using expression, which creates temporary objects, in `for(... : HERE)` or `for(... : indexed(HERE))`. The current C++ destroys the temporary object too early therefore this becomes UB.
|
||||
- Prefer Inverse of Control (IoC) and other design patterns, over trivial virtual functions, over switch-case on types, over if-else on types.
|
||||
- Prefer static dispatching over dynamic dispatching when possible and reasonable.
|
||||
|
||||
## Leveraging the Knowledge Base
|
||||
|
||||
- When making design or coding decisions, you must leverage the knowledge base to make the best choice.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Scrum
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Scrum.md` file should already exist, it may or may not contain content from the last scrum.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Design
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Scrum.md` file should already exist.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- `Copilot_Task.md` should be put in the same folder.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Planning
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Task.md` file should already exist.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- `Copilot_Planning.md` should be put in the same folder.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Summarizing
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Planning.md` file should already exist.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- `Copilot_Execution.md` should be put in the same folder.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Execution
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Execution.md` file should already exist.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
@@ -51,7 +51,7 @@ I am going to propose some change to the source code.
|
||||
- One build-fix process includes one attempt with the following instructions.
|
||||
- The main agent should call different sub agent for each build-fix process.
|
||||
- Do not build and retrieve build results in the main agent.
|
||||
- DO NOT delete the build log file.
|
||||
- DO NOT delete the `Build.log` if it is generated.
|
||||
|
||||
### Use a sub agent to run all following instructions (`Build the Solution`, `Fix Compile Errors`, `Code Generation`, `Finishing Code Change`)
|
||||
|
||||
@@ -105,4 +105,5 @@ I am going to propose some change to the source code.
|
||||
|
||||
- It will be covered by another separate phase.
|
||||
- You are good here.
|
||||
- DO NOT delete the build log file. The log file should remain untouched after finishing these instructions.
|
||||
- DO NOT delete the `Build.log` if it is generated.
|
||||
- It should remain untouched after finishing these instructions.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Verifying
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Execution.md` file should already exist.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
@@ -35,7 +35,7 @@
|
||||
- Check out `# AFFECTED PROJECTS` in `Copilot_Execution.md` to find out what solutions you need to build.
|
||||
- Find out if there is any warning or error.
|
||||
- `External Tools Environment and Context` in `REPO-ROOT/.github/copilot-instructions.md` has the instruction about how to check compile result.
|
||||
- DO NOT delete the build log file.
|
||||
- DO NOT delete the `Build.log` if it is generated.
|
||||
|
||||
#### Fix Compile Errors
|
||||
|
||||
@@ -75,7 +75,7 @@
|
||||
- One test-fix process includes one attempt following `Execute Unit Test` and `Fix Failed Test Cases`.
|
||||
- The main agent should call different sub agent for each test-fix process.
|
||||
- Do not test and retrieve test results in the main agent.
|
||||
- DO NOT delete the test log file.
|
||||
- DO NOT delete the `Execute.log` if it is generated.
|
||||
|
||||
### Use a sub agent to run the following instructions (`Execute Unit Test`, `Identify the Cause of Failure`, `Fix Failed Test Cases`)
|
||||
|
||||
@@ -120,4 +120,5 @@
|
||||
## Step 4. Check it Again
|
||||
|
||||
- Go back to `Step 2. Make Sure the Code Compiles`, follow all instructions and all steps again.
|
||||
- DO NOT delete the build/test log files. The log files should remain untouched after finishing these instructions.
|
||||
- DO NOT delete the `Build.log` or `Execute.log` if they are generated.
|
||||
- They should remain untouched after finishing these instructions.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Task
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
|
||||
## Goal and Constraints
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Investigate
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- Check out `External Tools Environment and Context` in `REPO-ROOT/.github/copilot-instructions.md` for accessing scripts for testing and debugging.
|
||||
- Check out `REPO-ROOT/Project.md` to find out what solutions you need to build.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_Investigate.md` file should already exist, it may or may not contain content from the last investigation.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Sync Knowledge Base with other Repos
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
|
||||
Here is a list of all repos, the `.github` folder should sync with each other:
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Update Knowledge Base
|
||||
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- The `Copilot_KB.md` file should already exist, it may or may not contain content from the last knowledge base writing.
|
||||
- If you cannot find the file, you are looking at a wrong folder.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Refine
|
||||
|
||||
- Check out `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
|
||||
## Goal and Constraints
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Review
|
||||
|
||||
- Check out `Accessing Task Documents` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` files.
|
||||
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
|
||||
- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
|
||||
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
|
||||
|
||||
## Goal and Constraints
|
||||
|
||||
Reference in New Issue
Block a user