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: docs/coding-guidelines/coding-style.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,7 @@ The general rule we follow is "use Visual Studio defaults".
36
36
37
37
An [EditorConfig](https://editorconfig.org"EditorConfig homepage") file (`.editorconfig`) has been provided at the root of the runtime repository, enabling C# auto-formatting conforming to the above guidelines.
38
38
39
-
We also use the [.NET Codeformatter Tool](https://github.com/dotnet/codeformatter) to ensure the code base maintains a consistent style over time, the tool automatically fixes the code base to conform to the guidelines outlined above.
39
+
We also use the [dotnet-format Tool](https://github.com/dotnet/format) to ensure the code base maintains a consistent style over time, the tool automatically fixes the code base to conform to the guidelines outlined above.
@@ -45,7 +45,7 @@ reserved bits should be written as zero. Diagnostic tooling may ignore non-zero
45
45
46
46
The `descriptor` is a pointer to a UTF-8 JSON string described in [data descriptor physical layout](./data_descriptor.md#Physical_JSON_descriptor). The total number of bytes is given by `descriptor_size`.
47
47
48
-
The auxiliary data for the JSON descriptor is stored at the location `aux_data` in `aux_data_count` pointer-sized slots.
48
+
The auxiliary data for the JSON descriptor is stored at the location `pointer_data` in `pointer_data_count` pointer-sized slots.
49
49
50
50
### Architecture properties
51
51
@@ -83,7 +83,7 @@ a JSON integer constant.
83
83
"globals":
84
84
{
85
85
"FEATURE_COMINTEROP":0,
86
-
"s_pThreadStore": [ 0 ] // indirect from aux data offset 0
86
+
"s_pThreadStore": [ 0 ] // indirect from pointer data offset 0
Copy file name to clipboardexpand all lines: docs/project/list-of-diagnostics.md
+1
Original file line number
Diff line number
Diff line change
@@ -109,6 +109,7 @@ The PR that reveals the implementation of the `<IncludeInternalObsoleteAttribute
109
109
|__`SYSLIB0052`__| This API supports obsolete mechanisms for Regex extensibility. It is not supported. |
110
110
|__`SYSLIB0053`__| AesGcm should indicate the required tag size for encryption and decryption. Use a constructor that accepts the tag size. |
111
111
|__`SYSLIB0054`__| Thread.VolatileRead and Thread.VolatileWrite are obsolete. Use Volatile.Read or Volatile.Write respectively instead. |
112
+
|__`SYSLIB0055`__| The underlying hardware instruction does not perform a signed saturate narrowing operation, and it always returns an unsigned result. Use the unsigned overload instead. |
We have multiple different mechanisms of executing tests.
138
+
139
+
Our test entrypoints are generally what we call "merged test runners", as they provide an executable runner project for multiple different test assemblies. These projects can be identified by the `<Import Project="$(TestSourceDir)MergedTestRunner.targets" />` line in their .csproj file. These projects provide a simple experience for running tests. When executing a merged runner project, it will run each test sequentially and record if it passes or fails in an xunit results file. The merged test runner support runtime test filtering. If specified, the first argument to the test runner is treated as a `dotnet test --filter` argument following the xUnit rules in their documentation. Today, the runner only supports the simple form, a substring of a test's fully-qualified name, in the format `Namespace.ContainingTypeName.TypeName.Method`. If support for further filtering options is desired, please open an issue requesting it.
140
+
141
+
Some tests need to be run in their own process as they interact with global process state, they have a custom test entrypoint, or they interact poorly with other tests in the same process. These tests are generally marked with `<RequiresProcessIsolation>true</RequiresProcessIsolation>` in their project files. These tests can be run directly, but they can also be invoked through their corresponding merged test runner. The merged test runner will invoke them as a subprocess in the same manner as if they were run individually.
142
+
143
+
#### The Standalone Test Runner and Build Time Test Filtering
144
+
145
+
Sometimes you may want to run a test with the least amount of code before actually executing the test. In addition to the merged test runner, we have another runner mode known as the "Standalone" runner. This runner is used by default in tests that require process isolation. This runner consists of a simple `try-catch` around executing each test sequentially, with no test results file or runtime test filtering.
146
+
147
+
To filter tests on a merged test runner built as standalone, you can set the `TestFilter` property, like so: `./dotnet.sh build -c Checked src/tests/path/to/test.csproj -p:TestFilter=SubstringOfFullyQualifiedTestName`. This mechanism supports the same filtering as the runtime test filtering. Using this mechanism will allow you to skip individual test cases at build time instead of at runtime.
148
+
149
+
#### Building all tests with the Standalone Runner
150
+
151
+
If you wish to use the Standalone runner described in the [previous section](#the-standalone-test-runner-and-build-time-test-filtering), you can set the `BuildAllTestsAsStandalone` environment variable to `true` when invoking the `./src/tests/build.sh` or `./src/tests/build.cmd` scripts (for example, `export BuildAllTestsAsStandalone=true` or `set BuildAllTestsAsStandalone=true`). This will build all tests that are not directly in a merged test runner's project as separate executable tests and build only the tests that are compiled into the runner directly. If a runner has no tests that are built directly into the runner, then it will be excluded.
152
+
133
153
### Building C++/CLI Native Test Components Against the Live Ref Assemblies
134
154
135
155
By default, the _C++/CLI_ native test components build against the _ref pack_ from the SDK specified in the `global.json` file in the root of the repository. To build these components against the _ref assemblies_ produced in the build, pass the `-cmakeargs -DCPP_CLI_LIVE_REF_ASSEMBLIES=1` parameters to the test build. For example:
@@ -233,9 +253,7 @@ cd path/to/JIT/Intrinsics/MathRoundDouble_ro
0 commit comments