* Build IJW assemblies against LKG SDK ref pack.
* Allow building against the live ref assemblies by passing `-cmakeargs -DCPP_CLI_LIVE_REF_ASSEMBLIES=1` to the test build script.
* Add test instructions
* Error handling
* Add support for the stdcall-mangled _CorDllMain entrypoint on x86 since MSVC uses it if it exists.
* Write out ref-pack path.
* Resolve MakeGenericType ILLink warning in DependencyInjection
Resolve the ILLink warning in DependencyInjection by adding a runtime check that is behind a new AppContext switch 'Microsoft.Extensions.DependencyInjection.VerifyOpenGenericServiceTrimmability'. The runtime check ensures the trimming annotations on the open generic types are compatible between the service and implementation types. The check is enabled by default when PublishTrimmed=true.
* Make VerifyOpenGenericServiceTrimmability a full feature switch
* Added Visual Studio build tools (#55629)
Added description of build tools (CMake, Ninja and Python) installation as Visual Studio Individual Components.
Added emphasis (bold) of Visual Studio installer sections and components (replaces previously used different styles of quotes).
* Removed Python 32-bit VS component
Python 64-bit component is enough for building x86 and x64 target architectures.
Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>
* Copy ILLink.LinkAttributes from mono to shared.
* Update ILLink.LinkAttributes that are now shared between mono and coreclr
- Move IntrinsicAttribute to mono only
- Introduce feature switches for NullabilityInfoContext and AggressiveAttributeTrimming
- Minor other cleanup
* Respect the NullabilityInfoContext.IsSupported feature switch in NullabilityInfoContext.
* Document new feature switches
* Add trimming tests for NullabilityInfoContextSupport
* Move NonVersionableAttribute to mono-only
* Fix Linq tests now that the ExtensionAttribute isn't being trimmed all the time on mono WASM
Move the metadata update related APIs to the MetadataUpdater class
The old APIs AssemblyExtensions.ApplyUpdate() and AssemblyExtensions.GetApplyUpdateCapabilities() will be removed
after all the references to them have been changed to the new APIs.
Add the new IsSupported API described in issue https://github.com/dotnet/runtime/issues/51159.
Change the tests to use the MetadataUpdater APIs.
Fix the ApplyUpdate qcalls and icalls
Add the ILLink substitutions for MetadataUpdater.IsSupported property
Change the old APIs to call the new ones
Update mono's MetadataUpdater.IsSupported property
Update feature switch doc
Fixed the argument checking in coreclr's MetadataUpdater.ApplyUpdate().
Bumps emscripten to 2.0.23
The Browser AOT tests now use `-Wl,-lto-O0` option to reduce memory usage of `wasm-ld` tool, which was in some cases going over avaiable 8GB on helix machines.
* Revert "Add ActiveIssue to the MemoryMappedFiles tests"
This reverts commit ec1ae530606ef1061680600fc046226cc1c4cbc3.
* Revert "Add ActiveIssue attr to the FileSystem tests"
This reverts commit 356b3ff2a703980ac01b9df697a594e8c341c436.
* Bump emscripten version to 2.0.23
* Use newer docker images with 2.0.23
* Update docs
* Use 2.0.23 emscripten nuget packages
* Revert "Revert "Add ActiveIssue attr to the FileSystem tests""
This reverts commit eb2f9548b08c114b359fab8d867ba50de098fe48.
The fix is not present in 2.0.23
* Revert "Revert "Add ActiveIssue to the MemoryMappedFiles tests""
This reverts commit 8be39f583499a8d8451034c65260a785330b0795.
The fix is not present in 2.0.23
* Increase timeout for AOT tests
* Add description of emscripten bump to README
* Try to get information about resources
* Get all limits
* Escape & chars
* Reduce platform matrix
* Lets try one more build with doubled timeout
* Revert "Lets try one more build with doubled timeout"
This reverts commit 67dd7754bb79218b2c6b687034162d041715093e.
* Try -Wl,-O0 on CI
To be sure it behaves the same as in local build
* Use -Wl,-lto-O0 do lower link time optimization
It looks like it reduces the memory load a lot
* Set EmccLinkOptimizationFlag for AOT tests
And reset the default value
* Escape commas
* Revert "Reduce platform matrix"
This reverts commit fec0e557208eb165824e75cd57b895a74d164de4.
* Remove resource info retrieval
* Bump emsdk versions
Co-authored-by: Larry Ewing <lewing@microsoft.com>
* Add warning on unmaintained testing doc page
* Update testing.md
Some example text that seems more clear to me, but only offered as a suggestion.
Feel free to adjust it or if you want to use it as-is please double check what I wrote is accurate : )
I think the useful elements are:
1. Being explicit about what workflow steps need to happen in total
2. Being explicit about which commands are covering the entire workflow and which ones are only covering a part of it
3. Show the simple "do-it-all" options first before showing more complex partial options. Glancing at the first example and blindly copying it should land in the pit of success.
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
* Bump emscripten version
* Rename __padding to _padding to avoid warnings
And errors as we use `-Werror`:
error G94F6014A: identifier '__padding' is reserved because it starts with '__'
C99 and C++ standard defines indentifiers with `__` prefix as reserved.
* Fix cast warning/error
With latest emscripten we get this warning (and error as we use
`-Werror`):
src/libraries/Native/Unix/System.Native/pal_process.c(374,92): error G3DC5E52A: cast from 'void (*)(int, siginfo_t *, void *)' to 'void (*)(int)' converts to incompatible function type [-Werror,-Wcast-function-type]
void (*oldhandler)(int) = (((unsigned int)sa_old.sa_flags) & SA_SIGINFO) ? (void (*)(int))sa_old.sa_sigaction : sa_old.sa_handler;
* Add `-s DISABLE_EXCEPTION_CATCHING=0`
when building dotnet.js
* Use EMSDK_PYTHON
* Use delayed expansion
Before the `EMSDK_PYTHON` was evaluated before running
the `emsdk_env.bat` script.
* Replace deprecated EXTRA_EXPORTED_RUNTIME_METHODS
with EXPORTED_RUNTIME_METHODS
Build warning/error:
emcc : warning : EXTRA_EXPORTED_RUNTIME_METHODS is deprecated, please use EXPORTED_RUNTIME_METHODS instead [-Wdeprecated]
* Don't need to cast anymore
* 2.0.21 was just released, so try our luck ;-)
* Use new docker images with 2.0.21
* Use the sys includes fix on all platforms
* Remove deprecated --llvm-opts usage
Context: 0691cc68ee
* Update emscripten version in the workload manifest
* Update emscripten versions in the docs
* Update eng/ versions
* Add ActiveIssue attr in the MemoryCacheTest
* Add ActiveIssue attr to the FileSystem tests
* Update after merge
* Resolve one more conflict
* Add ActiveIssue to the MemoryMappedFiles tests
* Revert "Fix cast warning/error"
This reverts commit 0a1aa4a88c07bc48d3d35c68369d1dca4897d849.
* Unset HAVE_FORK for Browser
* Remove active issue
Fixed by 93cf5df65f
* Set HAVE_FORK to 0
* Set HAVE_FORK to 0 instead if unsetting
* Remove -s DISABLE_EXCEPTION_CATCHING=0
It might not be needed anymore
* Update testing docs with x86 instructions
* Apply suggestions from code review
Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com>
* add more examples
* Apply suggestions from code review
Co-authored-by: Dan Moseley <danmose@microsoft.com>
* Update docs/workflow/testing/libraries/testing.md
Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com>
Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com>
Co-authored-by: Dan Moseley <danmose@microsoft.com>
Co-authored-by: Eric StJohn <ericstj@microsoft.com>
Add an NSAutoreleasePool to all managed create threads including the Main and Finalizer.
This expands the current support where support was only added to ThreadPool threads.
New feature switch was created and the ThreadPool one was removed.
- System.Threading.Thread.EnableAutoreleasePool
Updated AutoReleaseTest for the new scenarios.
* corerun supports user defined properties from command line.
* Update workflow help doc for corerun.
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Since AOT'ing each test suite takes between 3-9 min, we need to shift the burden over to helix.
## This is done by:
1. building the test assemblies on the build machine
- the wasm part of the build is not executed on the build machine,
because it has the AOT build part
2. Zip up the test assembly+friends, *and* any bits required to run the wasm
app build for that on helix (eg. emsdk, wasm app targets, cross compiler etc)
3. Send all this to helix, and use a custom `aot-build.proj`
- which recreates all the build inputs for the `WasmBuildApp` target
using the paths for the assets on helix
- then we can run `WasmBuildApp` for the build, resulting in a wasm app
bundle.
4. Run the tests!
- We already have the bits required for building wasm apps on helix, supported
for `Wasm.Build.Tests`, which we can use here too.
## Trimming:
- Since, AOT can be so expensive, we use `EnableAggressiveTrimming=true`(EAT), but
that means that we could have issues due to trimming.
- And it can sometimes be unclear whether the build/test failures are due to trimming
or AOT.
- Because these builds+test runs are different from other builds, owing to the
"build partially on helix" step, a normal EAT build would not be the same as
- to help with testing this, we add two lanes to `runtime-staging`:
- `*_Mono_AOT`: builds AOT+EAT on helix
- `*_Mono_EAT`: builds EAT, on helix
- this is required because we want to run almost the same kinda
build: 1. build test assembly; *2. send to helix; 3. build wasm app;* 4. run tests
- This should effectively mean that we can see which errors might be due to EAT, and
which are clearly because of EAT+AOT.
Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
Co-authored-by: Marek Safar <marek.safar@gmail.com>
Co-authored-by: Mitchell Hwang <mitchell.hwang@microsoft.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
* Add MachO dump writer to createdump
Instead of the hacky ELF core dumps on MacOS now createdump generates true MachO dumps.
Setting the COMPlus_DbgEnableElfDumpOnMacOS environment variable is no longer needed.
Add special thread info memory region containing the OS thread ids missing from macho core dumps. This allows SOS to map the thread indexes to thread ids. The address (0x7fffffff00000000) of this special memory region is above the highest user address (0x0007FFFFFFFFF000) and below a kernel reserved address (0xffffff8000xxxxxx) which is kind of moot because dumps don't include any kernel regions. lldb seems just fine with this memory region.
The changes include ARM64 support also, but since I don't have a M1 device I can't build/test them. I'm hoping Steve can at least review them.
Add --verbose/TRACE_VERBOSE support to tone down all the macho dump generation spew.
Issue: #48664
* Fix build problem
* Update docs
* Code review feedback
Co-authored-by: Juan Sebastian Hoyos Ayala <juhoyosa@microsoft.com>
We have a bunch of test assemblies that don't make sense on some platforms, e.g. Browser.
Right now we're skipping them via `[SkipOnMono("reason", TestPlatforms.Browser)]` but there's nothing that inherently ties this to Mono other than the current implementation.
The more generic `SkipOnPlatform` attribute can be used instead.
We can also use it in places where we do `[PlatformSpecific(~TestPlatforms....)]` to avoid the double inversion.