Sync with upstream main branch #28
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…otnet#62822) The macOS arm64 was using a new mechanism to implement FlushProcessWriteBuffers because the original one based on a wired memory page doesn't work on arm64. We have seen people hitting problems with the wired memory page allocation on x64 in the past due to the fact that wired memory is a scarce resource and in some cases, e.g. in presence of apps that greedily grab all of the available wired memory pages, we were unable to initialize coreclr and execute any .NET application. This change switches x64 to the same mechanism as arm64 to prevent that issue from happening and updates the minimum supported x64 macOS to 10.14. That's the version required for the new APIs the change is using. Apple stopped supporting 10.13 a year ago anyways.
* Remove the VN quirk * Delete the costing quirk
…Access IOException. (dotnet#62396) * Directory.Delete: prefer DirectoryNotFoundException over UnauthorizedAccess IOException. * Refactor error handling.
* Delete GT_SIMD_CHK and GT_HW_INTRINSIC_CHK
The former was unused, the latter - barely used.
Overall, there is no need for these to be separate
opers, it just leads to unnecessary `#ifdef`s.
* Remove IsArrayBoundsCheck
In loop cloning: redundant with the check for constant lengths below.
In assertion propagation: needless pessimization.
In range check: not needed. While it is not useful to search for the
array lengths from "new int[] { ... }" expressions, it is still useful
to look for assertions related to them.
* GTF_ARR_BOUND_INBND -> GTF_CHK_INDEX_INBND
* Fix formating
* [wasm] Don't emit warning if runtimeconfig.json cannot be found
Library projects don't have runtimeconfig.json files by default. So,
don't make it a warning. Instead, emit a low importance which might be
useful when debugging.
But library projects can have runtimeconfig.json, like the runtime test
projects. So, don't limit processing that by OutputType.
IOW, if it's found then use it.
* [wasm] Add timestamp to logs
* Download dotnet-install script for installing workloads
Instead of trying to use the script from `.dotnet`, download the script.
`.dotnet` might not exist, for example, when the `global.json` version
matches the system installed one.
* [wasm] WasmAppBuilder: catch UnauthorizedAccessException also
* [wasm] Fix bug in tests
Some helper methods have a `Action<JToken>` parameter. Many tests
pass an async lambda to this, expecting it to get awaited upon.
```csharp
EvaluateAndCheck (Action<T> locals_fn)
{
...
locals_fn(); // no await
...
}
async Task Test()
{
EvaluateAndCheck( async (locals) => {
...
CheckNumber(locals, ...);
await CheckDateTime(locals, ..);
...
} );
}
```
In the above example, roslyn generates an async-void lambda, so the
compiler never complains about the async lambda being passed.
`EvaluateAndCheck` cannot, and does not await this, but if the lambda happens to
block, then it will return at that point, and the test(calling method) will end,
without ever completing the lambda. And for most tests, the actual
checks are done in that lambda.
This gets hit when `CheckDateTimeValue` tries to fetch properties of a
`DateTime` object. And it started to show up when adding
`ConfigureAwait(false)` to some calls.
* [wasm] Add Wasm.Debugger.Tests wrapper project
This is a proxy/wrapper project for `src/mono/wasm/debugger/DebuggerTestSuite/DebuggerTestSuite.csproj`.
- Building the project as part of the regular browser-wasm build
presents some issues, because of part the tests need use the aspnet
sdk, and that doesn't work with `browser-wasm`.
- This wrapper project essentially builds the `DebuggerTestSuite`
project, with some
properties(`TargetFramework;TargetFrameworks;Configuration;TargetOS;TargetArchitecture`)
removed so they don't propogate from the parent build.
- And it packages it up for running the tests on helix
- I did try to convert `DebuggerTestSuite` into a `Wasm.Debugger.Tests`,
and make it use the library tests infrastructure, but ran into an
issue
- it built the project with no `testhost.dll`, so can't use `dotnet
test`
- it did get `xunit.console.dll`, but that would fail to run the tests
because of missing `System.Runtime` (and I'm guessing, other
assemblies)
- attempts to publish the project failed
- So, for now, this is what we have!
* [wasm][tests] Make them friendly to running outside the tree
.. like on helix.
Add new `DEBUGGER_TEST_PATH`, and `CHROME_PATH_FOR_DEBUGGER_TESTS` which
will be set for helix.
And change the appbundle directory name from the misleading `publish/`
to `AppBundle/`.
* [wasm] Tests.cs -> MiscTests.cs
* [wasm] Add support for submitting debugger tests to helix
Also, added `eng/testing/scenarios/WasmDebuggerTestsJobsList.txt` which
is a manually generated list of test classes. This will be changed to be
generated at runtime, in an upcoming PR.
* [wasm] Add debugger tests job for linux, and windows
They follow the same pattern as other wasm jobs:
- build when isFullMatrix
- build in runtime-manual
- Additionally, build when there are changes in:
```
- src/mono/wasm/debugger/*
- src/mono/wasm/runtime/*
- src/mono/mono/*
```
* [wasm] Add new make targets to submit tests to helix
`submit-debugger-tests-helix`
`submit-tests-helix` - submits any library test archives
* Build Wasm.Debugger.Tests from src/libraries/tests.proj
* DebuggerTestSuite: Copy files for the test archive
* [wasm] Fix HarnessTests.BrowserClose
* [wasm] Fix building `ApplyUpdateReferencedAssembly` project on CI
Essentially, disable use of SourceLink which gets enabled by default
when using `-p:ContinuousIntegrationBuild=true`.
Issue: dotnet#62618
* cleanup
* Wasm.Build.Tests: add missing file
* [wasm] sendtohelixhelp.proj: Error out if there is more than one zip
.. file when running for Wasm.Build.Tests, or Wasm.Debugger.Tests .
* [wasm] Disable DebuggerTests.ArrayTests on helix
Issue: dotnet#62661
Using `[Trait..` instead of `ActiveIssue` because: dotnet#62660
* disable non-wasma builds
* sendtohelixhelp.proj: guard against no payload found
* Disable more tests
* add back builds
* [wasm][debugger] Disable failing debugger test
`DebuggerTests.BreakpointTests.BreakpointInAssemblyUsingTypeFromAnotherAssembly_BothDynamicallyLoaded`
Issue: dotnet#62823
* Try to fix windows command line
* Move debugger-tests for linux to runtime-staging
* Revert "[wasm][debugger] Fix source-link test (dotnet#62786)"
.. as it is breaking debugger tests build on windows.
Issue: dotnet#62892
This reverts commit 8151740.
…2861) arithm32_cs_d: duplicate of arithm32_d arithm32_cs_do: duplicate of arithm32_do arithm64_cs_d: duplicate of arithm64_d with the only difference that arithm64_d was Pri1. I have kept arithm64_d (due to the shorter name) but I deleted the Pri1 specifier. arithm64_cs_do: duplicate of arithm64_do with the only difference that aritm64_do was Pri1. I have kept arithm64_d (due to the shorter name) but I deleted the Pri1 specifier. gc_nested: duplicate of gc_nested_d nested: duplicate of nested_d gcreport: duplicate of gcreport_d native: duplicate of native_d virtcall: duplicate of virtcall_d refanyval: duplicate of refanyval_d In all five cases I kept the version with _d for symmetry with the other build options (_do / _r / _ro). _XAssemblytest1-xassem: duplicate of _XModuletest1_xmod _XAssemblytest2-xassem: duplicate of _XModuletest2_xmod _XAssemblytest4-xassem: duplicate of _XModuletest4_xmod In these three cases I kept the _XModuletest variants that have compilation files and project references organized as two item groups that is the most prevalent style in our projects. The _Xmoduletest variants are apparently missing a boilerplate comment that is of little use. Thanks Tomas
* callback to make waiting on module load easier
`<TrimmerRootAssembly Include="myEntrypointAssembly" />` won't actually root anything with IL Linker. NativeAOT would do what it's instructed to do. This is showing up as a difference because the SDK auto-injects this root into all trimmed projects.
* Fix duplicated FldSeq in block morphing Reusing the address for the first field is problematic as the first field is likely to be at a zero offset, thus a zero-offset field sequence will be attached to it, and subsequent copies of the same tree will pick it up, which is incorrect. Fix by reusing the address for the last field instead. * Add a test * Add a description of the issue to the test
Every unwind fragment should be non-zero sized. If we consider splitting on a boundary that would create a zero-sized fragment, don't report that one. This only occurs when setting the stress mode JitSplitFunctionSize to something small.
Iteration count was dropped to a smaller number in dotnet/corert#2867. Looks like it's not enough because we see this test fail in the CI.
…oid emulators and arm64 devices (dotnet#62767) Just blindly disabling several crypto tests near which crashes have been observed for a while (based on a couple of the mobile targets rolling build runs). Disabled tests: - System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadWriteDiminishedDPPrivatePkcs1 - System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadEncryptedDiminishedDP_EmptyPassword - System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.DecryptPkcs12PbeTooManyIterations - System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadWriteRsa2048EncryptedPkcs8_Pbes2HighIterations - System.Security.Cryptography.Dsa.Tests.DSAKeyFileTests.cs.DecryptPkcs12PbeTooManyIterations - System.Security.Cryptography.Dsa.TestsDSAKeyFileTests.cs.ReadWriteDsa1024EncryptedPkcs8_Pbes2HighIterations - System.Security.Cryptography.Tests.ECKeyFileTests.DecryptPkcs12PbeTooManyIterations - System.Security.Cryptography.Tests.ECKeyFileTests.ReadWriteEc256EncryptedPkcs8_Pbes2HighIterations - System.Security.Cryptography.EcDsa.Tests.ECDsaTests_Span See also dotnet#62547.
* OSR support for Arm64 Enable OSR for Arm64: * rename `FpToSpDelta` in `PatchpointInfo` to `TotalFrameSize` so it makes sense for both x64 and Arm64. * make it clear that the local offsets in `PatchpointInfo` are virtual (relative to the top of the frame). Adjust recorded Arm64 offsets to match. * add new jit config setting `JitEnableOSRRange` to allow selectively enabling OSR for only a subset of jitted methods. * Arm64 OSR method is passed Tier0 SP but not Tier0 FP, as Tier0 FP can point either at top or bottom of Tier0 frame depending on frame type. For Arm64 the OSR method establishes its own FP that chains to caller FP. (I will likely revise x64 to work this way too, as it makes simple FP chain stackwalks work out better). * The Arm64 OSR epilog gets an extra SP adjustment to remove the Tier0 frame. * The Arm64 OSR prolog gets a phantom SP adjustment in unwind to account for being passed the Tier0 SP. * pad OSR funclet frames with tier0 frame size so `PSPSym` ends up at the same caller-SP relative offset as the OSR frame * handle the large `fiSpDelta1` offsets from the funclet frame padding * local/arg init for the OSR frame from the Tier0 frame was moved into a new method `genEnregisterOSRArgsAndLocals`; implemented the ARM64 version. * sequencing of this initialization in the prolog reordered slightly to prevent inadvertent clobbering. * comments/code that referred to `original` or `old` method were revised to instead try and consistently use `tier0`. * support the mixed-altjit case for OSR by allocating a local copy of the patchpoint info with similar and plausible information. * add symbol table note for locals in OSR methods that live on the Tier0 frame. * fix `fgIsThrowHlpBlk` when called on an empty block * broaden the jit-experimental testing matrix to include Arm64.
…t#62394) * Introduce IsNeverNegative * Address feedback * Apply suggestions from code review Co-authored-by: SingleAccretion <[email protected]> * Address feedback * fix build on x86 Co-authored-by: SingleAccretion <[email protected]>
This test set contains several project groups exercising various primitive types using explicit and sequential layout. Each group comprises a variant source file implementing a sequential or explicit struct / class 'AA' with a field of the given type (e.g. expl_byte_1.cs / seq_byte_1.cs) and a common source file (body_byte.cs in this case) implementing a number of tests manipulating the type 'AA' that is shared by the explicit and the sequential variant of the project (e.q. expl_byte_1[_d/_r].csproj, seq_byte_1[_d/_r].csproj). The problem was that the Main method resided in the common source file so that it was always present twice - once for the sequential and once for the explicit variant of the test (ignoring the _d / _r flavors). After experimenting with several ways to refactor the tests I have come to the conclusion that the most straightforward way of deduplicating them is just moving the Main method out of the shared source code into the variant (explicit / sequential) sources that aren't shared. Thanks Tomas
…62936) String constructors implementation methods had a dummy this argument on CoreCLR, but not on other runtimes. It required ifdefs in the implementation. This change removes the ifdefs and makes the string constructors implementation methods uniform accross all runtimes. It is possible to do this cleanup now since we have just bumped R2R version band.
joncham
approved these changes
Dec 20, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automatically generated pull request to merge changes from the upstream main branch.