Merge branch 'main' into copilot/refactor-string-comparison-logic

Author: MihaZupan

.devcontainer/devcontainer.json

@@ -14,7 +14,9 @@
 	},
 
 	"features": {
-		"ghcr.io/devcontainers/features/github-cli:1": {}
+		"ghcr.io/devcontainers/features/github-cli:1": {},
+		"ghcr.io/devcontainers/features/sshd:1": {},
+		"ghcr.io/devcontainers/features/copilot-cli:1": {}
 	},
 
 	// Configure tool-specific properties.

.gitattributes

@@ -81,4 +81,4 @@ src/tests/JIT/Performance/CodeQuality/BenchmarksGame/reverse-complement/revcomp-
 src/tests/JIT/Performance/CodeQuality/BenchmarksGame/k-nucleotide/knucleotide-input.txt text eol=lf
 src/tests/JIT/Performance/CodeQuality/BenchmarksGame/k-nucleotide/knucleotide-input-big.txt text eol=lf
 src/mono/browser/runtime/dotnet.d.ts text eol=lf
-src/native/corehost/browserhost/loader/dotnet.d.ts text eol=lf
+src/native/libs/Common/JavaScript/loader/dotnet.d.ts text eol=lf

.github/skills/jit-regression-test/SKILL.md

@@ -1,19 +1,28 @@
 ---
 name: jit-regression-test
-description: Extract a standalone JIT regression test case from a given GitHub issue and save it under the JitBlue folder. Use this when asked to create or extract a JIT regression test from an issue.
+description: >
+  Extract a standalone JIT regression test case from a given GitHub issue and
+  save it under the JitBlue folder. USE FOR: creating JIT regression tests,
+  extracting repro code from dotnet/runtime issues, "write a test for this JIT
+  bug", "create a regression test for issue #NNNNN", converting issue repro to
+  xunit test. DO NOT USE FOR: non-JIT tests (use standard test patterns),
+  debugging JIT issues without a known repro, performance benchmarks (use
+  performance-benchmark skill).
 ---
 
 # JIT Regression Test Extraction
 
-When you need to extract a JIT regression test case from a GitHub issue, follow this process to create a properly structured test under `src/tests/JIT/Regression/JitBlue/`.
+> 🚨 **Do NOT create a test when**: the issue has no reproducible code and you cannot compose a minimal repro, the issue is a duplicate of an existing test under `JitBlue/`, or the bug is in libraries/runtime rather than the JIT compiler itself.
+
+Extract a JIT regression test case from a GitHub issue into a properly structured test under `src/tests/JIT/Regression/JitBlue/`.
 
 ## Step 1: Gather Information from the GitHub Issue
 
 From the GitHub issue, extract:
-1. **Issue number** - Used to name the test folder and files (e.g., issue #99391 → `Runtime_99391`)
-2. **Reproduction code** - The C# code that demonstrates the bug. If no code provided, try to compose it yourself.
-3. **Environment variables** - Any DOTNET_* environment variables required to reproduce the bug
-4. **Expected behavior** - What the correct output/behavior should be
+1. **Issue number** → folder/file name (e.g., #99391 → `Runtime_99391`)
+2. **Reproduction code** — if none provided, compose a minimal repro yourself
+3. **Environment variables** — any `DOTNET_*` vars needed to reproduce
+4. **Expected behavior** — correct output/behavior
 
 ## Step 2: Create the Test Directory
 
@@ -52,8 +61,9 @@ public class Runtime_<issue_number>
 
 - **License header**: Always include the standard .NET Foundation license header
 - **Class name**: Match the file name exactly (`Runtime_<issue_number>`)
-- **Test method**: Use `[Fact]` attribute and name the method `TestEntryPoint()` or `Test()`
-- **Assertions**: Use Xunit's helpers or just throw plain exceptions.
+- **Test method**: `[Fact]` attribute, named `TestEntryPoint()` 
+- **Minimize the reproduction**: Strip to the minimal case that triggers the bug
+- **Use `[MethodImpl(MethodImplOptions.NoInlining)]`** when preventing inlining is needed to reproduce
 
 ### Example: Simple Test (from Runtime_99391)
 
@@ -86,13 +96,15 @@ public class Runtime_99391
 }
 ```
 
-## [Optional] Step 4: Create a .csproj File (Only When Needed)
+## Step 4: Create a .csproj File or add to the existing Regression_*.csproj
 
 A custom `.csproj` file is **only required** when:
 - Environment variables are needed to reproduce the bug (such as `DOTNET_JitStressModeNames`)
 - Special compilation settings are required
 
-It should be located next to the test source file with the following name: `Runtime_<issue_number>.csproj`. Example:
+Otherwise, register the test file in the existing `src/tests/JIT/Regression/Regression_*.csproj` (`Regression_ro_2.csproj` is a good default) file and skip creating a new .csproj.
+
+If a custom .csproj file is needed, it should be located next to the test source file with the following name: `Runtime_<issue_number>.csproj`. Example:
 
 ```xml
 <Project Sdk="Microsoft.NET.Sdk">
@@ -110,9 +122,7 @@ It should be located next to the test source file with the following name: `Runt
 </Project>
 ```
 
-## Important Notes
+## Tips
 
-- **No .csproj needed for simple tests**: Most tests only need the `.cs` file. The test infrastructure uses default settings that work for most cases.
-- **Look at recent tests**: When in doubt, examine recent tests under `src/tests/JIT/Regression/JitBlue/Runtime_*` for the latest conventions.
-- **Use `[MethodImpl(MethodImplOptions.NoInlining)]`**: When you need to prevent inlining to reproduce a JIT bug.
-- **Minimize the reproduction**: Strip down the test code to the minimal case that reproduces the issue.
+- **No .csproj needed for simple tests** — register the `.cs` file in `Regression_ro_2.csproj` instead.
+- **Look at recent tests** under `src/tests/JIT/Regression/JitBlue/Runtime_*` when in doubt about current conventions.

.github/skills/performance-benchmark/SKILL.md

@@ -3,9 +3,10 @@ name: performance-benchmark
 description: Generate and run ad hoc performance benchmarks to validate code changes. Use this when asked to benchmark, profile, or validate the performance impact of a code change in dotnet/runtime.
 ---
 
-# Ad Hoc Performance Benchmarking
+# Ad Hoc Performance Benchmarking with @EgorBot
 
-When you need to validate the performance impact of a code change, follow this process to write a BenchmarkDotNet benchmark and trigger EgorBot to run it.
+When you need to validate the performance impact of a code change, follow this process to write a BenchmarkDotNet benchmark and trigger @EgorBot to run it.
+The bot will notify you when results are ready, so don't wait for them.
 
 ## Step 1: Write the Benchmark
 
@@ -120,50 +121,37 @@ public class Bench
 }
 ```
 
-## Step 2: Post the EgorBot Comment
+## Step 2: Mention @EgorBot in a comment/PR description
 
 Post a comment on the PR to trigger EgorBot with your benchmark. The general format is:
 
-```
-@EgorBot [target flags] [options] [BenchmarkDotNet args]
+@EgorBot [targets] [options] [BenchmarkDotNet args]
 
 ```cs
 // Your benchmark code here
 ```
-```
-
-### Target Flags (Required - Choose at Least One)
+> **Note:** The @EgorBot command must not be inside the code block. Only the benchmark code should be inside the code block.
 
-| Flag | Architecture | Description |
-|------|--------------|-------------|
-| `-x64` or `-amd` | x64 | Linux Azure Genoa (AMD EPYC) - default x64 target |
-| `-arm` | ARM64 | Linux Azure Cobalt100 (Neoverse-N2) |
-| `-intel` | x64 | Azure Cascade Lake (more flaky due to JCC Erratum and loop alignment sensitivity) |
-| `-windows_x64` | x64 | Windows x64 (when Windows-specific testing is needed) |
+### Target Flags
 
-**Choosing targets:**
+- `-linux_amd`
+- `-linux_intel`
+- `-windows_amd`
+- `-windows_intel`
+- `-linux_arm64`
+- `-osx_arm64` (baremetal, feel free to always include it)
 
-- **Default for most changes**: Use `-x64` for quick verification of non-architecture/non-OS specific changes
-- **Default when ARM might differ**: Use `-x64 -arm` if there's any suspicion the change might behave differently on ARM
-- **Windows-specific changes**: Use `-windows_x64` when Windows behavior needs testing
-- **Noisy results suspected**: Use `-arm -intel -amd` to get results from multiple x64 CPUs (note: `-intel` targets are more flaky)
+The most common combination is `-linux_amd -osx_arm64`. Do not include more than 4 targets.
 
 ### Common Options
 
-| Option | Description |
-|--------|-------------|
-| `-profiler` | Collect flamegraph/hot assembly using perf record |
-| `--envvars KEY:VALUE` | Set environment variables (e.g., `DOTNET_JitDisasm:MethodName`) |
-| `-commit <hash>` | Run against a specific commit |
-| `-commit <hash1> vs <hash2>` | Compare two commits |
-| `-commit <hash> vs previous` | Compare commit with its parent |
+Use `-profiler` when absolutely necessary along with `-linux_arm64` and/or `-linux_amd` to include `perf` profiling and disassembly in the results.
 
 ### Example: Basic PR Benchmark
 
 To benchmark the current PR changes against the base branch:
 
-```
-@EgorBot -x64 -arm
+@EgorBot -linux_amd -osx_arm64
 
 ```cs
 using BenchmarkDotNet.Attributes;
@@ -182,73 +170,17 @@ public class Bench
     }
 }
 ```
-```
-
-### Example: Benchmark with Profiling and Disassembly
-
-```
-@EgorBot -x64 -profiler --envvars DOTNET_JitDisasm:SumArray
-
-```cs
-using System.Linq;
-using BenchmarkDotNet.Attributes;
-using BenchmarkDotNet.Running;
-
-BenchmarkSwitcher.FromAssembly(typeof(Bench).Assembly).Run(args);
-
-public class Bench
-{
-    private int[] _data = Enumerable.Range(0, 1000).ToArray();
-
-    [Benchmark]
-    public int SumArray() => _data.Sum();
-}
-```
-```
-
-### Example: Compare Two Commits
-
-```
-@EgorBot -amd -commit abc1234 vs def5678
-
-```cs
-using BenchmarkDotNet.Attributes;
-using BenchmarkDotNet.Running;
-
-BenchmarkSwitcher.FromAssembly(typeof(Bench).Assembly).Run(args);
-
-public class Bench
-{
-    [Benchmark]
-    public void TestMethod()
-    {
-        // Benchmark code
-    }
-}
-```
-```
-
-### Example: Run Existing dotnet/performance Benchmarks
-
-To run benchmarks from the dotnet/performance repository (no code snippet needed):
-
-```
-@EgorBot -arm -intel --filter `*TryGetValueFalse<String, String>*`
-```
-
-**Note**: Surround filter expressions with backticks to avoid issues with special characters.
 
 ## Important Notes
 
 - **Bot response time**: EgorBot uses polling and may take up to 30 seconds to respond
 - **Supported repositories**: EgorBot monitors `dotnet/runtime` and `EgorBot/runtime-utils`
 - **PR mode (default)**: When posting in a PR, EgorBot automatically compares the PR changes against the base branch
 - **Results variability**: Results may vary between runs due to VM differences. Do not compare results across different architectures or cloud providers
-- **Check the manual**: EgorBot replies include a link to the [manual](https://github.com/EgorBot/runtime-utils) for advanced options
+- **Check the manual**: EgorBot replies include a link to the [manual](https://github.com/EgorBo/EgorBot?tab=readme-ov-file#github-usage) for advanced options
 
 ## Additional Resources
 
 - [Microbenchmark Design Guidelines](https://github.com/dotnet/performance/blob/main/docs/microbenchmark-design-guidelines.md) - Essential reading for writing effective benchmarks
 - [BenchmarkDotNet CLI Arguments](https://github.com/dotnet/BenchmarkDotNet/blob/master/docs/articles/guides/console-args.md)
-- [EgorBot Manual](https://github.com/EgorBot/runtime-utils)
-- [BenchmarkDotNet Filter Simulator](http://egorbot.westus2.cloudapp.azure.com:5042/microbenchmarks)
+- [EgorBot Manual](https://github.com/EgorBo/EgorBot?tab=readme-ov-file#github-usage)

.github/workflows/aspnetcore-sync.yml

@@ -42,7 +42,7 @@ jobs:
         mkdir ..\artifacts
         git status > ..\artifacts\status.txt
         git diff > ..\artifacts\diff.txt
-    - uses: actions/upload-artifact@v6
+    - uses: actions/upload-artifact@v7
       with:
         name: results
         path: artifacts

.github/workflows/breaking-change-doc.yml

@@ -66,7 +66,7 @@ jobs:
         GITHUB_MODELS_API_KEY: ${{ secrets.MODELS_TOKEN }}
 
     - name: Upload artifacts
-      uses: actions/upload-artifact@v6
+      uses: actions/upload-artifact@v7
       with:
         name: breaking-change-doc-artifacts-${{ inputs.pr_number || github.event.pull_request.number }}
         path: artifacts/docs/breakingChanges/

.github/workflows/jit-format.yml

@@ -46,7 +46,7 @@ jobs:
           ROOTFS_DIR: ${{ matrix.os.rootfs }}
 
       - name: Publish format.patch
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v7
         with:
           path: runtime/format.patch
           name: format.${{matrix.os.name}}.patch

.markdownlint.json

@@ -1,6 +1,6 @@
 {
   "default": false,
   "MD009": {
-    "br_spaces": 0
+    "br_spaces": 2
   }
 }

Directory.Build.props

@@ -138,6 +138,7 @@
     <WasmProjectRoot>$([MSBuild]::NormalizeDirectory($(MonoProjectRoot), 'wasm'))</WasmProjectRoot>
     <WasiProjectRoot>$([MSBuild]::NormalizeDirectory($(MonoProjectRoot), 'wasi'))</WasiProjectRoot>
 
+    <CoreclrRuntimeBinDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'coreclr', '$(TargetOS).$(TargetArchitecture).$(Configuration)'))</CoreclrRuntimeBinDir>
     <AppleAppBuilderDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'AppleAppBuilder', '$(TasksConfiguration)', '$(NetCoreAppToolCurrent)'))</AppleAppBuilderDir>
     <AndroidAppBuilderDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'AndroidAppBuilder', '$(TasksConfiguration)', '$(NetCoreAppToolCurrent)', 'publish'))</AndroidAppBuilderDir>
     <MobileBuildTasksDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'MobileBuildTasks', '$(TasksConfiguration)', '$(NetCoreAppToolCurrent)'))</MobileBuildTasksDir>

docs/design/coreclr/botr/clr-abi.md

@@ -721,9 +721,17 @@ Structs are generally returned via hidden buffers, whose address is supplied by
 
 ### Prolog
 
-The prolog will increment the stack pointer, home any arguments that are stored on the linear stack, and zero initialize slots on the linear stack as appropriate. It will establish a frame pointer if one is needed.
+The prolog will decrement the stack pointer by the fixed frame size, home any arguments that are stored on the linear stack, and zero initialize slots on the linear stack as appropriate. It will establish a frame pointer if one is needed.
 
-It will also save a frame descriptor onto the stack, for use during GC and EH. For methods with EH or with GC safe points, a slot on the linear stack will be reserved for a "virtual IP" that will index into the EH and GC info to provide within-method information and allow external code to walk the managed stack frames.
+So on exit from the prolog the stack pointer (`$sp`) will point to the bottom of the fixed part of the stack frame. The frame pointer (`$fp`) if used, will also point to the bottom of fixed part of the stack frame. `$sp` and `$fp` will only differ in methods that can allocate extra storage on the stack at runtime (typically from `localloc`). The stack is kept 16 byte aligned.
+
+For methods that can be interrupted by GC or EH (generally speaking: methods with gc safe calls) the prolog also saves a frame descriptor onto the stack, for use during GC and EH. By convention this value is stored at `fp[0]`. Since only `sp` will be available for unwinding (by virtue of being saved to `$__stack_pointer`) we adopt the convention that when `$sp` moves in the middle of the method, `$sp[0]` is set to `$fp`.
+
+Thus to access information for EH/GC/unwinding, the frame descriptor `fd` can be found from the managed frame `$sp` as follows:
+* `fd = $sp[0]`
+* if `fd` is a stack address, it is the saved `$fp`. So then `fd = fd[0]`.
+
+We will save the "virtual IP" in a similar fashion (TBD: exact details on this).
 
 ### Epilog