| Age | Commit message (Collapse) | Author |
|---|
|
We now compile against the reference assembly in all places where we were compiling against the mono/coreclr System.Private.CoreLib.dll implementation assembly before.
The new reference assembly consumes sources from the existing contracts to avoid checking in a generated version of SPC.dll (this would add ~20k lines of .cs which is mostly duplicated with System.Runtime.cs)
Since a few contracts have only partially moved types to SPC we wrap contract types with `#if !BUILDING_CORELIB_REFERENCE` so we can hide them when compiling the SPC reference assembly. This needed a few GenAPI changes which are implemented here: https://github.com/dotnet/arcade/pull/10003.
Note that this means that the types which live in CoreLib are moved to the end of the ref .cs file which causes a GitHub diff to show up, but it is actually a no-op.
Regenerating the ref .cs files works the same way as before, by running the `GenerateReferenceAssemblySource` target in the contract's src\ folder.
Fixes https://github.com/dotnet/runtime/issues/67660
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
|
|
Fixes https://github.com/dotnet/runtime/issues/29154. I didn't introduce a new target to keep the validation cost as low as possible.
|
|
Merge initial work on multi-threaded WebAssembly.
The normal wasm build is single-threaded. There should be no functional changes to its behavior.
To enable a multi-threaded build pass `/p:WasmEnableThreads=true`. See `src/mono/wasm/threads.md` for details.
The big changes are:
1. The normal ref assemblies related to threading retain `[UnsupportedOSPlatform("browser")]` attributes for various threading-related functions
2. In System.Private.CoreLib, the `[UnsupportedOSPlatform]` attributes are removed, and functions that used to always throw PNSE nwo do a runtime check using `System.Threading.Thread.IsThreadStartSupported` to check if threading is enabled in the current build.
3. A new nuget `Microsoft.NET.WebAssembly.Threading` is created. It contains experimental ref assemblies without the `[UnsupportedOSPlatform]` attributes. The intention is that code opting into experimenting with multithreading will include this nuget by setting some property that will be used by the wasm MSBuild SDK to pick a multi-threaded runtime build and configure things appropriately. (The SDK updates don't exist yet).
4. In the multi-threaded runtime we don't use Emscripten's "main thread" option (ie: the browser thread is the main one); we also continue to run certain runtime-internal jobs (finalizers, GC pump) on the main thread even in the multi-threaded runtime.
Remaining work is tracked in the related issue https://github.com/dotnet/runtime/issues/68162
---
* Initial changes for emscripten 2.0.34
* Use emcc-link.rsp in build targets
* Use updated docker images
* Fix compiler warnings
* Put `--profiling-funcs` to `_EmccLinkFlags`
* Fix build
src/mono/mono/mini/mini-runtime.c:3407:25: error: ‘invoke’ undeclared (first use in this function); did you mean ‘revoke’?
3407 | invoke = mono_marshal_get_runtime_invoke_dynamic ();
* Add shell to the environment
Environment setting https://github.com/emscripten-core/emscripten/blob/2.0.34/src/settings.js#L616-L641
From emscripten 2.0.25 release notes
- Support for the 'shell' environment is now disabled by default. Running under
`d8`, `js`, or `jsc` is not something that most emscripten users ever want to
do, so including the support code is, more often than not, unnecessary. Users
who want shell support can enable it by including 'shell' in `-s ENVIRONMENT`
(#14535).
Example of the the size increase for bench sample:
-a--- 12/10/2021 3:35 PM 382113 dotnet.js
-a--- 12/13/2021 10:37 AM 383589 dotnet.js
* Add emcc-link.rsp to PlatformManifestFileEntry
* Feedback
https://github.com/emscripten-core/emscripten/blob/2fda25eea756c78c8cb024aa5b6c2b188bf7990f/src/settings.js#L1173-L1176
-s EXPORT_ES6 is link option
* Bump emscripten version
* Bump llvm package version and use its libclang
* Use newer docker images with emscripten 3.1.1
* Remove unused variable
* Add runtime support for threads in the wasm build
To enable, pass `/p:WasmEnableThreads` when building the runtime
./build.sh -Subset mono+libs -os Browser -arch wasm /p:WasmEnableThreads=true
* Prevent runtime from starting twice when loaded in a web worker
* Automatically populate the emscripten mainScriptUrlOrBlob property so that worker initialization can find dotnet.js
* Add compatibility shim so that emscripten's generated worker.js can properly get a Module instance, since we broke the API
* Checkpoint
* Bring back threadpool and add some tracing in diagnostics
* Add comments and fix a typo
* Introduce 'MonoObjectRef' ts type. Migrate mono_string_intern to not have a retval
* Checkpoint (strings are broken for some reason)
* Fix string interning
* Migrate ObjectToString and GetDateValue
* Checkpoint gc safe/unsafe region work
* More ref conversion
* Checkpoint (broken?)
* Fix missing method
* Fix incorrect signatures
* Fix lint
* Add new 'R' signature char for 'ref object'
* Remove AddEventListener and RemoveEventListener Checkpoint
* eslint fixes
* Update call_method signature to avoid passing raw object pointers
* Ref-ify one websocket API and fix types and incorrect rooting of two others
* Deprecation metadata
* More ref
* Remove outdated comments
* Convert typed_array_new to ref
* Add volatile modifiers, satisfy eslint
* Update src/mono/wasm/runtime/corebindings.c
* Missing conflict
* Fix build, set coop gc, and always copy dotnet.worker.js when it's around for apps
* Disable sample profiler, add some functions that were missing from katelyn's PR.
* Add safepoint around ep_rt_wait_event_set. Tweak sample to explicitly exit wasm in order to properly flush event to the nettrace file (w/ rundown events).
* [gc] Start the GC Finalizer thread on threaded WASM
* [mono] add GC Unsafe in mono_assembly_load; remove in EventPipe
Remove GC Unsafe hack in ep_rt_wait_event_set
* post-merge cleanup: delete duplicated definitions
* [sample] Env vars should be stringy
* updated dotnet.d.ts
* Add mono_threads_wasm_async_run_in_main_thread; do background work on main
Don't start a finalizer thread
Queue all background work to run on the main thread
* [mono] Fix non-threaded wasm build
* Add a System.Threading.Thread.WebAssembly.Threading ref assembly
* Update the browser sample to use System.Threading.Thread.WebAssembly.Threading
* Rationalize System.Threading.Thread build
In CoreLib, never add the [UnsupportedOSPlatform("browser")] attribute. Rely on runtime checks (`ThrowIfNoThreadStart()`). In System.Threading.Thread ref assembly, always add the unsupported platform
attribute. Add mismatches to ApiCompat baseline. In System.Threading.Thread.WebAssembly.Threading don't add the attributes, and also set DisablePackageBaselineValidation to prevent Restore from looking for a System.Threading.Thread.WebAssembly.Threading nuget (fixes in-tree ProjectReferences for testing)
* only turn on analyzers for the browser sample
not all wasm samples
* Make a single Microsoft.NET.WebAssembly.Threading nupkg
that holds all the special ref assemblies
* works: sample has ProjectReference to the Microsoft.NET.WebAssembly.Threading.proj
* Add System.Threading.ThreadPool.WebAssembly.Threading ref assembly
* ThreadPool: throw PNSE if no thread start
* Update wasm threads.md
* apicompat: correct warnings for System.Threading.ThreadPool
* Add dotnet.worker.js to the runtime pack; update PlatformManifestFileEntry
* [wasm] startup: detect Blazor dotnet.[version].[hash].js location
Blazor injects a `<link rel="modulepreload" />` element into the header when it boots; detect it and extract the URL of the script.
This is needed by Emscripten's dotnet.worker.js to run WorkerGlobalScope.importScripts
* one more fix to Microsoft.NET.WebAssembly.Threading
Seems to be necessary in order for the resulting .nupkg not to reference non-existent nugets for the ProjectReferences
* rename sample to browser-mt-eventpipe
* bring back unmodified browser sample
The multithreading sample is browser-mt-eventpipe
* update browser-mt-eventpipe sample to use ref assembly refs
Referencing the rollup Microsoft.NET.WebAssembly.Threading.proj doesn't work (it ends up bundling the ref assemblies into the publish dir and breaking the app)
* Use correct ifdef in AppContext.AnyOS.cs
* [build] support WasmEnableThreads and WasmEnablePerfTracing
These toplevel options either turn on multi-threading in general, or turn on multithreading only for eventpipe internals.
For libraries these define `FeatureWasmThreads` and `FeatureWasmPerfTracing` properties and the `FEATURE_WASM_THREADS` and `FEATURE_WASM_PERFTRACING` compiler constants.
For the native code, they control `DISABLE_THREADS` and `DISABLE_WASM_USER_THREADS` cmake and preprocessor settings.
* Only add the portable threadpool on wasm if threading is enabled
* rename browser-mt-eventpipe csproj and main assembly
Give it a unique name distinct from Wasm.Browser.CJS.Sample.csproj
* fix /p:WasmEnableThreads=false build after merge
* now fix the WasmEnableThreads=true build
* we need two ThreadPoolBoundHandle implementation stubs
one for PortableThreadPool when threads are enabled, one for single-threaded wasm
* Add a System.Diagnostics.Tracing ref assembly gated by FeatureWasmPerfTracing
* [eventpipe] use the correct cmake option name
see src/mono/mono.proj
* revert debug printf and commented out code
* turn off additional logging
* hack: set FeatureWasmPerfTracing in the browser-mt-eventpipe sample
It would be better to drive this (the inclusion of the tracing runtime component) from a user-visible flag. not the FeatureWasmPerfTracing implementation detail
* remove unused variable, remove unneeded configure checks, revert line damage; add better comment in export.ts
* Exclude Microsoft.NET.WebAssembly.Threading from testPackages.proj
* review feedback, Apply suggestions from code review
* Use a testPackages settings file to skip package runtime item verification
* remove unneeded Directory.Build.props for ref package
since ti doesn't compile its own assembly, none of these properties are needed
* use one ProjectReference item to share metadata for the ref assemblies
* remove ProjectReference comment and NoTargetsDoNotReferenceOutputAssemblies prop
* Remove unneeded target
* packaging simplification
- move `_ExperimentalUpdateFileVersion` target to packaging.targets, conditioned on a new `IsExperimentalRefAssembly` attribute. (The target increments the file version of the ref assembly to make it easier to distinguish from the real non-experimental ref assembly)
- Remove unneeded src subdirectories in ref assembly libraries
- Move properties that are only used in the ref assembly projects directory into the projects and delete Directory.Build.props in the experimental ref assembly subdirectories.
* move and rename UpdateExperimentalRefAssemblyFileVersion target
packages.targets is only included for IsPackable=true projects, and these ref assemblies are not packable.
* Assorted code review nits
* Don't build/pack the multi-threaded sample on single-threaded runtime
* remove gratuitous debug printfs
* Apply suggestions from code review
* merge followup: nullable is enabled by default now
* make eslint happy
* include wasm-config.h in wasm runtime host
* include wasm-config.h into the runtime pack
fixes aot compilation
* Add wasm-config.h to manifest
* put wasm-config.h into include/wasm from the outset
* put back noExitRuntime replacement for CJS
Co-authored-by: Radek Doulik <radekdoulik@gmail.com>
Co-authored-by: Radek Doulik <radekdoulik@google.com>
Co-authored-by: Zoltan Varga <vargaz@gmail.com>
Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
Co-authored-by: Katelyn Gadd <kg@luminance.org>
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
|
|
detection (#65896)
* Make Is*Project properties unambiguous
Currently these properties exist which categorize projects:
- IsReferenceAssembly: The project's parent directory is 'ref'
- IsGeneratorProject: The project's parent directory is 'gen'
- IsTestProject: The project is located somewhere under a '/tests/'
directory and the project name's suffix is either
'.Tests' or '.UnitTests'.
- IsTrimmingTestProject: Same as IsTestProject but the project name's
suffix is '.TrimmingTests'.
- IsTestSupportProject: The project is located somewhere under a
'/tests/' directory and the above IsTestProject
property is false.
- UsingMicrosoftNoTargetsSdk: The project uses the NoTargets msbuild SDK
- UsingMicrosoftTraversalSdk: The project uses the Traversal msbuild SDK
- IsRuntimeAssembly: True when all above is false
- IsSourceProject: True when the project's parent directory is 'src'
The IsRuntimeAssembly and IsSourceProject properties meanings are
ambiguous and the property names aren't consistent (IsReferenceAssembly
vs IsGeneratorProject).
I'm changing the above to the following:
- **IsReferenceSourceProject: The project's parent directory is 'ref'
or the parent of the parent directory is 'ref'**
- IsGeneratorProject: The project's parent directory is 'gen'
- IsTestProject: The project is located somewhere under a '/tests/'
directory and the project name's suffix is either
'.Tests' or '.UnitTests'.
- IsTrimmingTestProject: Same as IsTestProject but the project name's
suffix is '.TrimmingTests'.
- IsTestSupportProject: The project is located somewhere under a
'/tests/' directory and the above IsTestProject
**and IsTrimmingTestProject** props are false.
- UsingMicrosoftNoTargetsSdk: The project uses the NoTargets msbuild SDK
- UsingMicrosoftTraversalSdk: The project uses the Traversal msbuild SDK
- IsSourceProject: **True when all above is false.**
* React to PR feedback
|
|
Split the build of shared framework and out-of-band projects so that
it's possible to just build the shard framework projects, which was
requested by the CLR teams. In the next infrastructure rollout, the
current "libs.ref+libs.src" subsets should be removed. Generate the
targeting pack with an incomplete (without shims) frameworklist as part
of the "libs.sfx" subset.
Build the shim projects after the shared framework and oob projects and
re-generate the targeting pack's frameworklist to include the shims.
Refactor the shims so that they aren't grouped anymore by generated &
manual. Instead group them by "ref" and "src" same as other libraries
in the tree which allows to reference the source project shims and read
from the ReferenceAssembly metadata.
Use ProjectReferences in traversal projects and shim projects instead
of named references that point to binplace directories (see graph below)
This allows to build parts of the product dynamically, i.e. the shim
projects, apicompat.proj, sfx.proj and oob.proj.
|
|
* Avoid InitialTarget in libs tree for CoreLib
InitialTargets are quite expensive as they run for every project invocation, even if the target invoked doesn't require the InitialTarget to run. Libraries projects only have one InitialTarget for correctly referencing CoreLib which can be changed so that it runs before RAR.
|
|
* Subtract instead of cartesian product in targets
See https://github.com/dotnet/runtime/pull/64000#issuecomment-1030460532. These targets were quite expensive and noticeable in no-op builds. Instead of building the cartesian product via item batching, using subtraction which avoids unnecessary items to be computed.
* Update resolveContract.targets
* Update targetingpacks.targets
* Update resolveContract.targets
* Update resolveContract.targets
|
|
* Clean-up DllImportGenerator packaging infra
Most of what DllImportGenerator was trying to achieve via targets or by setting common packaging properties is already handled by libraries common packaging infrastructure (packaging.props) which is imported when a project sets `IsPackable=true`.
|
|
* Validate that reference assembly projects only reference other reference assembly projects
* Permit ref->src reference if src project produces reference assembly
* Move target to references.targets
|
|
* Don't reference ns.dll inside shared framework
The netstandard.dll shim shouldn't be referenced inside the shared
framework as it's a compat shim that shouldn't be required to compose
the shared framework.
This removes the necessity of a separate RefPath build and improves
incremental build times as only the few OOB projects that require the
shim would need to rebuild.
* Reference netstandard shim in OOBs that require it
There are a few OOB projects that require the netstandard.dll shim as
they intentionally reference projects that only expose a netstandard
configuration.
Co-authored-by: Buyaa Namnan <buyankhishig.namnan@microsoft.com>
|
|
* Add transitive CompilerServices.Unsafe dependency
for System.Memory and System.Threading.Tasks.Extensions package
references. Adding the dependency as a P2P to prefer the live asset
over the prebuilt.
|
|
* Fix build on some libs projects when metadata isn't available
* Update references.targets
|
|
- Remove depprojs which currently binplace external references into the RefPath folders in favor of PackageReference and PackageDownload items.
- Build all configurations by default when building an individual project (either on the CLI or inside VS) same as with the official SDK. This enables .NETFramework Test Explorer support.
- Centrally define libraries that compose the shared framework instead of in each Directory.Build.props file to be able to build the targeting pack first and consume it in the OOB libraries.
- Use ProjectReferences to reference OOB projects. Compile against the reference assembly but use the implementation assembly app-local during runtime.
- Remove OOBs from the testhost and remove the testhost folder for .NETFramework as it isn't required anymore.
- Only binplace for $(NetCoreAppCurrent) to compose a) the targeting pack, b) the runtime pack, c) the testhost, d) a full closure for the shims.
- Use Targeting Packs for OOB projects (with their implicit assembly references) but still explicitly define granular references for .NETCoreApp configurations (DisableImplicitAssemblyReferences switch). Use the implicit targeting pack references in some Microsoft.Extensions.* cases.
- Remove placeholder configurations as they aren't needed anymore with explicit P2Ps vs Targeting Pack references.
- Remove implicit assembly references (ie for .NETFramework, mscorlib)
- Remove AssemblySearchPath hacks that were introduced with b7c4cb7 as the targeting pack is now used by default.
- Reduce unnecessary .NETFramework configurations that were added to run tests in favor of the already existing ref&src configurations.
- Stop hardcoding the paths for wasm assemblies and use the returned TargetPath of the ProjectReferences.
- Addressed formatting (ItemGroups, References at the bottom of the project file, ordering of references, use LibrariesProjectRoot instead of a relative path, unnecessary AssemblyName and RootNamespace properties which are identical to the project name, ordering of tfms)
- Revert "fix clean (#33758)"
|
|
* feedbacl from previous time
* remove TargetsNet* from ItemGroup
* removing targetFramework from .targets
|
|
* Enable dotnet test
* Update docs
* Use vstest in F5 scenarios
* Make dotnet test without framework switch work
* Code cleanup
* Only run code coverage conditionally
* Fix F5 condition for netcoreapp
* Downgrade sdk to check for helix submission failures
* Fix wrong conditions
* Add blame data collector
|
|
* Add Libraries Testing framework package as inline
The existing package Microsoft.DotNet.CoreFxTesting lived in Arcade
because of no infrastructure being available to compile local tasks in
the repository. As the runtime repository now offers that we can inline
the testing framework.
* Hardcode configuration for installer.tasks
* Update ReportGenerator global tool version
* Add vstest support
* Update binary serialization blobs
|
|
Commit migrated from https://github.com/dotnet/corefx/commit/26d7b6626ab0385a1158e674855f81ab73f628e0
|
|
Commit migrated from https://github.com/dotnet/corefx/commit/7264bc96154f937dd69ff971f6be695de0a13a13
|
|
(dotnet/corefx#37375)
* React to APICompat changes enabling reverse APICompat for facades
* Fix UAP and NETFX reverse APICompat issues
* Fix reverse APICompat baseline for allconfigurations build
* Manually update to latest APICompat
* Manually update to latest CoreCLR and fix issues
* Baseline System.Threading.Tasks
* Revert "Manually update to latest CoreCLR and fix issues"
This partially reverts commit dotnet/corefx@ee800617b6a52cc66ac3214717f34b8896320ef9.
I'm keeping the baseline changes which will be needed when we get a new update.
* Temporarily baseline DiagnosticCounter API gaps
This can be removed when get a new CoreCLR
That's currently blocked due to regressions in tests.
Commit migrated from https://github.com/dotnet/corefx/commit/035343743c5a7f67be8a2a2f36913a3c43893b76
|
|
(dotnet/corefx#34979)
Commit migrated from https://github.com/dotnet/corefx/commit/38b2d1d4e298a717d99adadcfb0803a8e2a0b04f
|
|
* Remove buildtools imports from Directory.Build.*
Remove buildtools imports and implement remaining functionality in CoreFx.
I was able to do most of what BuildTools was doing with 3 exceptions, which will be split into separate issues.
1. Test shared framework deps file: GenerateDepsJson. We need to port this task to arcade or change how we test to not need it.
2. codeOptimization.targets -> should be moved to arcade, work is pending.
3. optionalTooling.targets -> move to a CSProj that is restored by the official build workflow.
* Address feedack, fix unix and UAP build issues
* Fix UWP, Tizen, and AllConfigurations build
* Remove buildtools dependency from package testing
* Remove a few more buildtools dependencies
* Eliminate RunningOnUnix property
* Remove NuGetTargetMoniker from shims.proj
* Remove ResourcesFolderPath
* Fix Microsoft.XmlSerializer.Generator.Tests
* Specify NuGetTargetMoniker for shims
* Remove a couple remaining ToolsDir uses
Commit migrated from https://github.com/dotnet/corefx/commit/49d249fa023e8575dba7e35febb4446e4fa13f98
|
