* Work in progress: new Sdk that selects mono runtime components
* Add props and targets description to the components doc
* condition the _MonoRuntimeAvailableComponents by RuntimeIdentifier
* [cmake] Write a component-manifest.props file during build
If we're not building a mono aot cross compiler, generate a
component-manifest.props file in artifacts/obj/mono/<host>/ that indicates if
the host will use static or dynamic components, and a list of the available
components, and the properties for constructing their names.
* Build Microsoft.NETCore.App.Runtime.Mono.<RID>.Sdk shared framework nuget
It seems to also generate a symbols nuget. And in the nuget there's a
tools/mono-sdk-what-is-this.deps.json file from the
SharedFrameworkHostFileNameOverride property. It would be nice to exclude that
stuff.
* put the compoonent-manifest.targets into the Sdk
* delete WIP in mono/nuget/
* fixup static component names in component-manifest.targets
* delete fixed fixme
* add missing $
* fix whitespace
* [cmake] switch to configure_file instead of file(CONFIGURE)
* add missing trailing slashes in .props.in file
* Add new Sdk packs to the workload manifest
* rework component-manifest.targets to use ItemGroups; move to new SDK
* Rename shared framework to Microsoft.NETCore.App.Runtime.Mono.<RID>.Props.Sdk
And only include component-manifest.props, not the targets
* Update manifest to include the new Props.Sdk and MonoTargets.Sdk
* Move RuntimeConfigParserTask into Microsoft.NET.Runtime.MonoTargets.Sdk
Consolidate all platform-independent tasks and targets into a single Sdk
* Add iossimulator-x86 props
* update components design doc
* Fix typo
* improve docs
* Add _MonoRuntimeComponentDontLink target output
* Drop component-manifest.props into runtime pack build/ directory
Remove from the Microsoft.NETCore.App.Mono.Props.Sdk workload nuget
* remove Microsoft.NETCore.App.Mono.Props.Sdk
* Import component-manifest.props from the runtime pack
Move the MonoTargets.Sdk import to each target platform that we support
* Fix typos
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Apply suggestions from code review
Co-authored-by: Ankit Jain <radical@gmail.com>
* Add JsonToItemsTaskFactory
* fix whitespace
* Do some validation earlier in _MonoComputeAvailableComponentDefinitions
* Read component-manifest.json using the JsonToItemsTaskFactory
and bundle it in Microsoft.NET.Runtime.MonoTargets.Sdk
* remove ResolvedRuntimePack import from WorkloadManifest.targets
it's too early, and we have the JsonToItemsTaskFactory now to read the manifest
* Generate component-manifest.json in CMakeLists.txt
* Fix some copy-paste nits
* Use RuntimeFlavor==mono for runtime pack build directory
instead of TargetsMobile. We want the build files (mono-components.json)
in every mono runtime pack, not just on mobile targets
* Apply suggestions from code review
Co-authored-by: Ankit Jain <radical@gmail.com>
* rename component-manifest to RuntimeComponentManifest
* fixup nullability annotations
* fix whitespace
* fix formatting
* Misc fixes to JsonToItemsTaskFactory
* Rename MonoRuntimeComponentManifestReadTask
from MonoRuntimeComponentsReadManifestTask
* undo nullability annotation
Build doesn't like it for some reason (probably net472)
* fix incorrect task parameter name
* Remove Identity metadata from dictionary at json parsing time
Also improve nullability a bit by making the properties immutable
* Throw correct json deserializer exceptions
* Catch JsonException in an async function
We get nice error messages now like
```
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5): error : Failed to deserialize json from file 'artifacts/bin/mono/iOSSimulator.x64.Release/build/RuntimeComponentManifest.json', JSON Path: $.items._MonoRuntimeAvailableComponents[2], Line: 14, Position: 1 [component-manifest.sample.proj]
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5): error : JsonException: The JSON value could not be converted to System.Collections.Generic.Dictionary`2[System.String,System.String]. Path: $.identity | LineNumber: 0 | BytePositionInLine: 16. Path: $.items._MonoRuntimeAvailableComponents[2] | LineNumber: 14 | BytePositionInLine: 1. [component-manifest.sample.proj]
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5): error : InvalidOperationException: Cannot get the value of a token type 'Number' as a string. [component-manifest.sample.proj]
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5):
error :
[component-manifest.sample.proj]
```
* fixup comments
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
GC only ever needs to look at the top dispatcher frame as other
dispatchers cannot have live arg buffers, so it is not necessary to keep
these linked together. We can save a bit of stack this way.
Also update design document that was a bit outdated.
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>
* Expose missing refs from runtime in targeting pack
The platform analyzers warns for usages of APIs which aren't available
on specific platforms. Exposing the missing reference assemblies which
are already part of the runtime pack in the targeting pack.
The big benefit of doing so is that customers don't need to reference
the corresponding packages to target these APIs and that these five
packages can be dead-ended.
For more in-depth reasoning, see the detailed summary:
https://github.com/dotnet/runtime/issues/53892#issuecomment-858542280
Fixes https://github.com/dotnet/runtime/issues/53892
* Update dependents of dead-ended packages
Update depents by referencing the latest available package. Making sure
that packages are never used on NetCoreAppCurrent by applying
.NETCoreApp version conditions.
* Fixes
* Remove pkg validation suppression file
* Update Windows Compatibility pack
* Fix DirectoryServices pkg references
* Fix netfx Pkcs restore/build
* Fix version conflict
* Packageindex and nits
* nits
Address deficiencies in current devirtualization infrastructure
- Remove the responsibility of creating a CORINFO_RESOLVED_TOKEN structure from the JIT and make it a responsibility of the VM side of the jit interface.
- This enables the component (crossgen2) which has deeper understanding of the requirements here to correctly handle scenarios that would otherwise require expressing crossgen2 specific details across the jit interface.
- Add a new set of fixups (`READYTORUN_FIXUP_Check_VirtualFunctionOverride` and `READYTORUN_FIXUP_Verify_VirtualFunctionOverride`) these are used to validate that the behavior of the runtime and crossgen2 compiler is equivalent for a virtual resolution event
- `READYTORUN_FIXUP_Check_VirtualFunctionOverride` will ensure that the virtual resolution decision is the same at crossgen2 time and runtime, and if the decision differs, any generated code affected by the decision will not be used.
- `READYTORUN_FIXUP_Verify_VirtualFunctionOverride` will perform the same checks as `READYTORUN_FIXUP_Check_VirtualFunctionOverride`, but if it fails the check, the process will be terminated with a fail-fast. It is intended for use under the `--verify-type-and-field-layout` stress mode.
- Currently only the `READYTORUN_FIXUP_Verify_VirtualFunctionOverride` is actually generated, and it is only generated when using the `--verify-type-and-field-layout` switch to crossgen2. Future work will identify if there are scenarios where we need to generate the `READYTORUN_FIXUP_Check_VirtualFunctionOverride` flag. One area of possible concern is around covariant returns, another is around handling of type equivalence.
- In order to express the fixup signature for the VirtualFunctionOverride fixups, a new flag has been added to `ReadyToRunMethodSigFlags`. `READYTORUN_METHOD_SIG_UpdateContext` will allow the method signature to internally specify the assembly which is associated with the method token, instead of relying on the ambient context.
- R2RDump and the ReadyToRun format documentation have been updated with the details of the new fixups/flags.
- Update the rules for handling unboxing stubs
- See #51918 for details. This adds a new test, as well as proper handling for unboxing stubs to match the JIT behavior
- Also revert #52605, which avoided the problem by simply disabling devirtualization in the presence of structs
- Adjust the rules for when it is legal to devirtualize and maintain version resiliency
- The VersionsWithCode and VersionsWithType rules are unnecessarily restrictive.
- Instead Validate that the metadata is safely checkable, and rely on the canInline logic to ensure that no IL that can't be handled is inlined.
- This also involved adding a check that the chain of types from the implementation type to the declaration method table type is within the version bubble.
- And changing the `VersionsWithType` check on the implementation type, to a new `VersionsWithTypeReference` check which can be used to validate that the type can be referred to, in combination with using `VersionsWithType` on the type definition.
- By adjusting the way that the declMethod is referred to, it becomes possible to use the declMethod without checking the full method is `VersionsWithCode`, and it just needs a relationship to version matching code.
- In `resolveVirtualMethod` generate the `CORINFO_RESOLVED_TOKEN` structures for the jit
- In particular we are now able to resolve to methods where the decl method is the resolution result but is not within the version bubble itself. This can happen if we can prove that the decl method is the only method which can possibly implement a virtual.
- Add support for devirtualization reasons to crossgen2
- Port all devirtualization abort conditions to crossgen2 from runtime that were not already present
- Fix devirtualization from a canonical virtual method when the actual implementation is more exact
- Fix variant interface override scenario where there is an interface that requires implementation of the variant interface as well as the variant interface itself.
* Include NetCoreAppCurrent configs in packages
The NetCoreAppCurrent configurations were omitted from packages to avoid
ever growing packages. Now that we adhere to the support policy for
packages we don't need to exclude them anymore as the policy defines a
baseline for .NETCoreApp configurations.
This will remove an artificial difference when source building the
repository and also make it so that partner repositories which don't
depend on a transport package like windowsdesktop (winforms) receive
the very latest assets that are included in the shared framework as
well.
* Fix package validation for non exposed inbox libs
Just fixing up a couple of missing words I noticed in the intro chapter:
Missing "to" in "(more code that does not seem do much)"
Missing "a" in "This results in big productivity boost."
* 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>
* Remove the use of IsPartialFacadeAssembly in refererences
This flag requires assembly-re-writing to replace type-defs in reference
assemblies with type forwards, when the same type exists in references.
We've pretty much exclusively used this on .NETFramework, since it's
not friendly to source build (CCI isn't part of source build).
.NETFramework isn't going to be changing so it doesn't save us much
to generate these typeforwards in the build.
We also used these to make sure the netstandard surface area was
compatible with .NETFramework facades (we'd use the pre-rewritten
reference assemblies for contract), but this need goes away now that we
have package validation based APICompat that compares netstandard refs
to net4x facades.
* Fix some projects I missed after changing naming convention
* Fixup another project
* Fix build of System.System.Threading.AccessControl
* Adding a section to ref-source docs on .NETFramework facades
* Address feedback
* Add Analyzer packaging support and packaging documentation
To package Microsoft.Extensions.Logging.Abstractions we needed support
for packing an Analyzer. This adds that support.
I wanted to document this addition, so I created the start of a doc that's
meant to describe the packaging options for libraries in dotnet/runtime.
* Address code review feedback.
* More feedback
* Address more feedback
* Remove src.proj build of generators
* Update to use Microsoft.DotNet.PackageTesting
* Fix typos
* Fix package testing on net46*
