You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,11 +4,9 @@ excludeAgent: code-review-agent
4
4
5
5
**Any code you commit SHOULD compile, and new and existing tests related to the change SHOULD pass.**
6
6
7
-
You MUST make your best effort to ensure your changes satisfy those criteria before committing. If for any reason you were unable to build or test the changes, you MUST report that. You MUST NOT claim success unless all builds and tests pass as described above.
7
+
You MUST make your best effort to ensure any code changes satisfy those criteria before committing. If for any reason you were unable to build or test code changes, you MUST report that. You MUST NOT claim success unless all builds and tests pass as described above.
8
8
9
-
Do not complete without checking the relevant code builds and relevant tests still pass after the last edits you make. Do not simply assume that your changes fix test failures you see, actually build and run those tests again to confirm.
10
-
11
-
You MUST refer to the [Building & Testing in dotnet/runtime](#building--testing-in-dotnetruntime) instructions and use the commands and approaches specified there before attempting your own suggestions.
9
+
If you make code changes, do not complete without checking the relevant code builds and relevant tests still pass after the last edits you make. Do not simply assume that your changes fix test failures you see, actually build and run those tests again to confirm. You can avoid building if you only change comments or files that do not affect builds and tests (e.g. README.md).
12
10
13
11
You MUST follow all code-formatting and naming conventions defined in [`.editorconfig`](/.editorconfig).
14
12
@@ -23,6 +21,7 @@ In addition to the rules enforced by `.editorconfig`, you SHOULD:
23
21
- Prefer `?.` if applicable (e.g. `scope?.Dispose()`).
24
22
- Use `ObjectDisposedException.ThrowIf` where applicable.
25
23
- When adding new unit tests, strongly prefer to add them to existing test code files rather than creating new code files.
24
+
- When adding new unit tests, avoid adding a regression comment citing a GitHub issue or PR number unless explicitly asked to include such information.
26
25
- If you add new code files, ensure they are listed in the csproj file (if other files in that folder are listed there) so they build.
27
26
- When running tests, if possible use filters and check test run counts, or look at test logs, to ensure they actually ran.
28
27
- Do not finish work with any tests commented out or disabled that were not previously commented out or disabled.
@@ -53,7 +52,7 @@ In addition to the rules enforced by `.editorconfig`, you SHOULD:
53
52
54
53
## 1. Prerequisites
55
54
56
-
These steps need to be done **before** applying any changes.
55
+
These steps need to be done **before** applying any code changes.
57
56
58
57
### 1.1. Determine Affected Components
59
58
@@ -87,6 +86,7 @@ Before applying any changes, ensure you have a full successful build of the need
If changes are being made in the System.Private.CoreLib library, you can follow the Libraries steps, but you may want to use "-rc checked" instead of "-rc release"; that will result in asserts being included in the build rather than excluded.
90
90
91
91
3. Verify the build completed without error.
92
92
-_If the baseline build failed, report the failure and don't proceed with the changes._
@@ -234,6 +234,8 @@ If only one library is affected:
234
234
235
235
-`dotnet build /t:test` is generally preferred over `dotnet test`
236
236
237
+
System.Private.CoreLib is special. To rebuild CoreLib and prepare to run tests with the changes, `cd` into the root of the repo and run:
Copy file name to clipboardExpand all lines: docs/design/coreclr/botr/clr-abi.md
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -537,6 +537,10 @@ The extra state created by the JIT for synchronized methods (lock taken flag) mu
537
537
538
538
EnC is supported for adding and editing generic methods and methods on generic types and generic methods on non-generic types.
539
539
540
+
## Async methods
541
+
542
+
The JIT saves the current `ExecutionContext` and `SynchronizationContext` in runtime async methods and these must be preserved during remap. The new GC encoder includes the state in the EnC frame header size, while for JIT32 the EE expects this state to exist when `CORINFO_ASYNC_SAVE_CONTEXTS` was reported to the JIT from `getMethodInfo`.
543
+
540
544
# Portable entrypoints
541
545
542
546
On platforms that allow dynamic code generation, the runtime abstracts away execution strategies for dynamically loaded methods by allocating [`Precode`](method-descriptor.md#precode)s. The `Precode` is a small code fragment that is used as a temporary method entrypoint until the actual method code is acquired. `Precode`s are also used as part of the execution for methods that do not have regular JITed or AOT-compiled code, for example stubs or interpreted methods. `Precode`s allow native code to use the same native code calling convention irrespective of the execution strategy used by the target method.
@@ -693,4 +697,4 @@ The stack elements are always aligned to at least `INTERP_STACK_SLOT_SIZE` and n
693
697
694
698
Primitive types smaller than 4 bytes are always zero or sign extended to 4 bytes when on the stack.
695
699
696
-
When a function is async it will have a continuation return. This return is not done using the data stack, but instead is done by setting the Continuation field in the `InterpreterFrame`. Thunks are responsible for setting/resetting this value as we enter/leave code compiled by the JIT.
700
+
When a function is async it will have a continuation return. This return is not done using the data stack, but instead is done by setting the Continuation field in the `InterpreterFrame`. Thunks are responsible for setting/resetting this value as we enter/leave code compiled by the JIT.
Copy file name to clipboardExpand all lines: docs/design/coreclr/botr/readytorun-platform-native-envelope.md
+3-7Lines changed: 3 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,9 +13,11 @@ The tentative high-level design is outlined below. As we implement this support,
13
13
## crossgen2: producing Mach-O object files
14
14
15
15
Mach‑O support will only be supported for composite ReadyToRun when the target OS is macOS. It will be opt-in via a new `crossgen2` flag:
16
+
16
17
-`--obj-format macho`
17
18
18
19
`crossgen2` will:
20
+
19
21
- Produce a Mach-O object file as the composite R2R image with the `RTR_HEADER` export for the `READYTORUN_HEADER`.
20
22
- Mark each input IL assembly as a component R2R assembly: `READYTORUN_FLAG_COMPONENT`.
21
23
- Mark each input IL assembly with a new flag indicating that the associated composite image is in the platform-native format: `READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE`
@@ -28,20 +30,14 @@ There's a few cases in the R2R format that are not natively represented in the M
28
30
29
31
#### Sections
30
32
31
-
Sections folded into `__TEXT,__text` that is in other sections in the PE envelope:
32
-
33
-
- CLR metadata: In the PE format, put in .cormeta, corresponds to the PE Header's "COR Header directory"
34
-
- Win32 Resources: In the PE format, put in .rsrc, corresponds to the PE Header's "Win32 Resources Header directory"
35
-
- Managed Unwind Info: In the Mach-O format, this section is expected to be in the Mach-O unwind format. The unwind info used by the runtime must be in the Windows unwind format.
36
-
- GC Info: Entries correspond to the unwind info.
37
33
38
34
Data moved out of `__TEXT,__text`:
39
35
40
36
- Precompiled managed code has been moved into `__TEXT,__managedcode`. `__TEXT,__text` gets special treatment by the linker and `__TEXT,__managedcode` matches NativeAOT.
37
+
- Read-only data such as jump tables, CLR metadata, Win32 Resources, managed unwind info, gc info, and the R2R headers are moved to `__TEXT,__const`
41
38
42
39
Data that stays in the corresponding locations as the PE envelope:
43
40
44
-
- Read-only data such as jump tables and the R2R headers: `__TEXT,__const`
45
41
- Read-write data, such as fixup tables: `__DATA,__data`
Copy file name to clipboardExpand all lines: docs/workflow/editing-and-debugging.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,8 +24,6 @@ The repository has a number of Visual Studio Solutions files (`*.slnx`) that are
24
24
*`coreclr` - This is the main runtime DLL (the GC, class loader, interop are all here)
25
25
*`corjit` - This is the Just In Time (JIT) compiler that compiles .NET Intermediate language to native code.
26
26
*`corerun` - This is the simple host program that can run a .NET application
27
-
*`crossgen` - This is the host program that runs the JIT compiler and produces .NET Native images (`*.ni.dll`)
28
-
for C# code.
29
27
* This project can be automatically generated and opened in Visual Studio by running `./build.cmd -vs CoreCLR.slnx -a <Arch> -c <BuildType>` from the root of the repository.
30
28
*`artifacts\obj\win-<Arch>.<BuildType>\corehost\ide\corehost.slnx` - this solution contains the native (C++) projects for the [host components](../design/features/host-components.md)
31
29
* This project can be automatically generated and opened in Visual Studio by running `./build.cmd -vs corehost.slnx -a <Arch> -c <BuildType>` from the root of the repository.
0 commit comments