Age | Commit message (Collapse) | Author |
|
* Update coding-style to include target-typed new guideline
Similar to `var` usage, `new()` usage is only allowed when the Type can be understood from the same line.
Fix #53369
* Fix coding style violations
|
|
marshaller types (#65591)
|
|
* Delete create-codespaces-prebuild.yml
* Remove reference to the prebuild action and link to the codespaces doc instead.
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
|
|
|
|
|
|
|
|
* Add table of testing configurations
* Remove "cross" from specification
|
|
|
|
|
|
obsolete (#66292)
Fixes #65545
|
|
|
|
|
|
|
|
* Use CMakeProjectReference instead of ProjectReference
Changing this permits usage of "\runtime\dotnet.cmd build" as opposed
to forcing users to use "\runtime\dotnet.cmd msbuild".
|
|
* Update Codeowners to remove imhameed
* Update area-owners.md to remove imhameed
* Update fabricbot.json file to remove imhameed
* update codeowners file to remove alexrp
* update codeowners to remove Egor from Mono files
* remove merp related entries from CODEOWNERS
Co-authored-by: Aleksey Kliger (λgeek) <alklig@microsoft.com>
Co-authored-by: Aleksey Kliger (λgeek) <alklig@microsoft.com>
|
|
|
|
Fixes #65546
|
|
|
|
|
|
instead of analyzer (#65915)
|
|
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.
|
|
* Update area-owners to use area team names for the libraries area pods
* Update fabricbot for libraries pod changes; remove configs for old project boards
* Remove intra-team consultants from libraries areas
|
|
|
|
|
|
* Create mono-thread-state-machine.md
Add the thread state machine design document
* Add some sequence diagrams
* Add hybrid suspend race sequence diagram
* More details on self-transitions
* fix coop GC suspend discussion
* undo accidental deletion
|
|
Rework x64 OSR so OSR methods have standard epilogs.
Details in attached doc.
|
|
* Update conversion code fix to offer multiple fixes for appending each previously probed entry-point suffix when ExactSpelling is false.
* Remove ExactSpelling property and move properties that were relying on ExactSpelling = false to use explicit entrypoint names.
* Emit ExactSpelling = true for all of our emitted target DllImports.
* Fix a few entry points
* Add a comment around CharSet.Auto
* Update compatibility doc.
* Update docs/design/libraries/DllImportGenerator/Compatibility.md
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Co-authored-by: Elinor Fung <elfung@microsoft.com>
|
|
* [LoongArch64] add ToolBox directory about jitinterace for getting ABI-info. (#59561)
Co-authored-by: Loongson's .NET-teams
* [LoongArch64] add new interace for getting ABI-info. (#59561)
* [LoongArch64] add the linking page for LoongArch64 ABI-info. (#59561)
* [LoongArch64] moved ThunkInput.txt to #62885.
* [LoongArch64] moved vm/jitinterface.cpp to #62885.
* remove the JIT/EE interface back from #62885..
* [LoongArch64] Fix the compiling error after merge.
* [LoongArch64] add comments for the returned value of `getFieldTypeByHnd`.
* [LoongArch64] rename getFieldTypeByHnd to getFieldSizeClassificationByHnd.
Also add macro define for returned value of `getFieldSizeClassificationByHnd`.
* [LoongArch64] Delete the interface `getArgType2`.
And refactor the returned values of `getFieldSizeClassificationByHnd`.
* [LoongArch64] delete `GetArgType` within `ToolBox/superpmi`.
* [LoongArch64] rename `getFieldSizeClassificationByHnd` to
`getLoongArch64PassStructInRegisterFlags`.
* [LoongArch64] amend the floating-ABI for native-struct.
* [LoongArch64] update all related `GetFieldSizeClassificationByHnd`
by `GetLoongArch64PassStructInRegisterFlags` and amend some comments.
* [LoongArch64] replace `LookupApproxFieldTypeHandle()`
by `GetFieldTypeHandleThrowing()`.
* [LoongArch64] implements the crossgen2 for LoongArch64.
* Revert "[LoongArch64] implements the crossgen2 for LoongArch64."
This reverts commit b05a2b90e8d8a2f6d1cf7f101ddfc9d4ed8d984e.
The crossgen2 for LoongArch64 will be submitted by a new PR.
* [LoongArch64] update the `GUID JITEEVersionIdentifier`.
Also delete some unused comments.
Co-authored-by: qiaopengcheng <qiaopengcheng-hf@loongson.cn>
|
|
|
|
|
|
|
|
* Initial proposed changes for ref fields
* Fix end of line issue
* Update docs/design/specs/Ecma-335-Augments.md
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
* Update local signature wording
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
|
|
* Don't use Targets* helper properties in libs projs
This change makes it possible to migrate 200+ (ref+src) projects to use
TargetFramework instead of TargetFrameworks which avoids the additional
outer build evaluation and invocation which ultimately makes the overall
build faster.
Targets* properties (i.e. TargetsWindows, TargetsAnyOS, TargetsUnix,
etc.) rely on the TargetFramework property which usually are set
inside a project. The TargetFramework property is only
available before a project specifies it if it's explicitly set in a props
file or if the project is cross-targeting and the outer-build dispatches
into the inner-build. During the dispatch, the TargetFramework property
is passed in as a global property.
Until now that behavior wasn't a problem because every libraries project
cross-targeted (by setting the TargetFrameworks property) even though
many only include a single TargetFramework (i.e. NetCoreAppCurrent).
To allow projects to use the TargetFramework property instead of
TargetFrameworks, the Targets* helper properties can't be calculated
anymore early in a props file as the TargetFramework property isn't set
at that time.
In general, the guidance by the SDK/msbuild team is to not read from the
TargetFramework property before the project sets it
(in a property group). That effectively means that the TargetFramework
property shouldn't be used in props files at all.
Therefore these helper properties can't be used anymore for property
conditions and I'm replacing their usage with TargetPlatformIdentifier
comparisons for both properties and items.
In nearly all cases, the Targets* helper properties can be replaced with
TargetPlatformIdentifier checks on items and in the few cases where
TargetsUnix or TargetsLinux marks multiple tfms as compatible, the exact
tfms must be used instead for the TargetPlatformIdentifier comparison.
Whenever a project needs to condition properties on the platform, I'm
first setting the TargetPlatformIdentifier the same way the SDK sets it
so that the SDK later doesn't need to set it again to avoid the
additional expensive msbuild function call.
* Use TargetFramework singular to avoid outer builds
Use TargetFramework instead of TargetFrameworks property whenever a
projects only targets a single target framework. This avoid unnecessary
outer builds and evaluations and makes the build faster.
|
|
* Update linux build instructions for .NET 6/7
* Add linux musl arm to the list
Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>
|
|
- The preview feature version of virtual statics implemented for .NET 6 does not allow for the interface methods to have a default implementation.
- With this change, we add support for the interface method having an actual implementation to CoreCLR. From what I can tell the Mono runtime already had such support
- There are some small ECMA spec updates to allow this change that are also included
In addition, I've taken the liberty to enable running the coreclr test suite on Mono on Windows. It needed a small amount of fixup.
|
|
- Move all SetScriptCommands to a target, so they are placed after scenario in the generated script.
- Add WasmXHarnessArgsCli as an alternative variable that can be used from cli.
- Fix NodeJS symbolic links on Helix.
- Copy TestEchoMiddleware and RemoteLoopMiddleware even for Scenario=NodeJS.
- Enable System.Net.WebSockets.Client.Tests on NodeJS.
|
|
* Remove NativeAOT testing added in dotnet/runtime#62704 to make room for the different strategy.
* Build NativeAOT as part of test build, not test run
|
|
Add support for generating control-flow guard checks. The support is enabled by a JIT flag or by setting COMPlus_JitForceControlFlowGuard=1.
Co-authored-by: Michal Strehovský <MichalStrehovsky@users.noreply.github.com>
|
|
Enable ARM64 libraries testing for NativeAOT.
* Copy the crosstargeting build approach from crossgen2. We'll now build two ILC compilers when targeting ARM64 from x64: an arm64-hosted one that is useless on the build machine, and a x64-hosted one, that will work on the build machine. The `ILCompiler.csproj/props/_crossarch.csproj` projects mirror crossgen's approach.
* Limit the number of libraries tests to one. Hopefully it avoids the build races that we'd see until we can update the repo build to .NET 7 Preview 1.
* Create an ARM64 NativeAOT CI leg that sends the libraries tests to Helix to run.
|
|
The link was not rendering correctly, as the link text and target were on separate lines.
|
|
The command `src/tests/build[.cmd|.sh] nativeaot [Debug|Release] tree nativeaot` seems not to work as expected.
Namely it seems to build not only the nativeaot smoke tests.
Fixed to be `src\tests\build[.cmd|.sh] -nativeaot [Debug|Release] -tree:nativeaot`
|
|
Information about how to think about OSR and to debug jit and runtime
when OSR is enabled.
|
|
* Remove .NETStandard runtime implementations
Remove the remaining ten .NETStandard runtime specific implementations.
For reasoning please see https://github.com/dotnet/runtime/issues/64536.
* Remove infra support for NS platform specific tfms
Also cleaning-up some logic and stop disabling AppendTargetFramework.
|
|
... you need to need to run library tests or run HelloWorld sample with your change to mono.
|
|
(#64595)
* Update area-owners verbiage about FabricBot configuration for notifications
* Add link to the automation.md doc
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
|
|
Official builds are currently not building NativeAOT CoreLib.
For unknown reasons the official build splits native build and managed build of the CoreCLR partition.
We had a convenient clr.nativeaotlibs subset that built both the native part and managed part. Managed part can't be built without the native part, so it makes sense.
To satisfy official build's weirdness, we need to split this into two subsets so that we can tell the official build to build the managed part. (Official builds already build everything in the native part, so we're good there.)
|
|
|
|
* [docs] Collecting stack traces with native symbols on WebAssembly
* Apply suggestions from code review
Co-authored-by: Larry Ewing <lewing@microsoft.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
Co-authored-by: Larry Ewing <lewing@microsoft.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
|
|
Fixes #63505
|
|
* [Android][libs] Enable Internal.Console.Write in System.Private.CoreLib
* [docs] Add debugging System.Private.CoreLib Internal.Console.Write
* Elaborate on debugging corelib log
* Address feedback
|