* Making System.Resources.ResourceManager trim safe
* Addressing PR Feedback
* Rename objects => types
* Also rename the strings.resx
* More PR Feedback
* Add UnconditionalSuppressMessage to Extensions
* Rename feature switch and reword error messages
* Removing new warning that is already addressed
* Rename AppContext switch and add feature switch to docs
* Addressing Feedback
* Revert changes to findtype plus some other feedback
* Revert FindType back
* move feature check up
* Add documentation on running tests using different Browsers other than chrome.
- XHARNESS_COMMAND="test-browser --browser=safari"
- Add ability to run against different browsers from the make file target `run-browser-tests` by adding `XHARNESS_BROWSER= ` to command line.
At the moment supported values are:
- `chrome`
- `safari`
- `firefox`
* Add gecko firefox requirements to testing docs.
* Improve generated dump debugging instructions
* Update eng/testing/debug-dump-template.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Update eng/testing/debug-dump-template.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Update eng/testing/debug-dump-template.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Update debug-dump-template.md
* Fix ```
* fix some ```cmd
* Reverse .cmd to .bat
* Open only for reading
* Improve foldername
* Install only one SOS
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
The current framework relays on CoreCLR to create the Core_Root and then patch it with mono runtime. So building CoreCLR is required before building runtime tests for desktop Mono
* Move DacTableGen out of the CMake build and into tools-local.
* Attempt: usenmakefiles means ninja.
* Make changes to Windows build to support non-VS generators like ninja.
* Use CMake 3.16 PCHs.
* Remove explicit process count.
* Build and run DacTableGen via the .NET CLI we pull down for the build instead of via CMake.
* Update configurecompiler.cmake to specify language (needed for Ninja).
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Get Ninja build working again.
* Pass configuration to cmake configure step for Ninja build.
* Rename flag
* Fix configure step for cross-arch native build
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Support building via Ninja for coreclr via an MSBuild property
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Implement support for opening the CoreCLR solution in VS via the -vs flag.
* Fix setting generator to Ninja.
* Merge libraries gen-buildsys-win.bat with runtime gen-buildsys.cmd to share windows cmake configure infra.
* Enable building libraries native build with ninja.
* Centralize setting CMAKE_SYSTEM_VERSION for windows builds.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Update host build to use shared gen-buildsys.cmd
* Fix multi-config generator detection.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Exit with success when we build successfully.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Enable and fix up Ninja build for hosts.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Only link delayimp.lib on Windows
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Remove "overriding /W3 with /W1" warning in Ninja build of hosts by turning on /W3 and disabling any new warnings we hit.
* Reduce command line override warnings by adopting the MSVC_RUNTIME_LIBRARY abstraction feature in CMake 3.14+ (below the minimum requirement on Windows).
* Use the delayed expansion syntax to correctly pass in the config to cmake.
* Move all usages of MSVC runtime library selection to the CMake abstraction to reduce console spew about overridden flags.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Condition the rest of the compiler options correctly so they don't show up as invalid parameter warnings for assembly builds.
* Correctly build DIALib and DacTableGen as AnyCPU
* Fix WRITE_BARRIER_CHECK define
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Fix passing arch for MSBuild build.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Configure ASM compiler command line format in configurecompiler.cmake and use CMake's assembly compilation step to build ASM files for ARM/ARM64 instead of manually building them and adding the generated files as additional sources.
* Cleanup after fixing ARM/ARM64 support.
* Rename variable
* Condition PCH's for C++-only as needed to fix using them on non-Windows (where we compile C as C instead of as C++).
* Fix CoreCLR native test build on windows to point to new gen-buildsys location.
* Add missing compilation options in Ninja build that are implicitly defined in the MSBuild build.
* Disable analyzers for DacTableGen. Remove /MAP linker flag (that's for local testing).
* Upgrade to CMake 3.16.4
* Don't warn on unused variables in CMake (these usually vary on platform/config)
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Manually compile ARM and ARM64 asm files when using the VS generator since it doesn't support emitting MARMASM item types in projects (and as a result cannot compile ARM or ARM64 asm without assistance).
* Enable CMake policy in test build to use CMAKE_MSVC_RUNTIME_LIBRARY variable.
* Update initially disabled warnings in host.
* Add -ninja arg to root scripts to enable using Ninja.
* Enable using Ninja in CoreCLR CI.
* Try to fix passing the -ninja arg in yaml.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Add ninja to the Windows invocation
* Fix 2-phase cross targeting to do one phase at a time and initialize the VC++ environment for the correct build tools each time instead of interleaving them and relying on Visual Studio to handle the differing targets.
* Restore old /Ox optimization setting for Release.
* Fix typos, don't pass exception flags to C files.
* Remove unneeded pragma.
* Fix .pgd file installation.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Add mention of the `-ninja` flag in the Building CoreCLR documentation.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
* Mention installation locations for Ninja and warn while building if CMake is older than 3.16.0.
* Update docs/workflow/requirements/windows-requirements.md
This change:
- Adds new options to mono.proj:
- MonoAOTEnableLLVM, which enables (or disables) building a Mono AOT
cross compiler with LLVM;
- MonoAOTLLVMDir, which specifies the path to a copy of LLVM suitable for
building a Mono AOT cross compiler, and is optional; and
- BuildMonoAOTCrossCompilerOnly, which allows building a Mono AOT
cross compiler without building an associated full Mono runtime.
- Changes offsets-tool.py's user interface slightly; '--include-prefix' is
renamed to '--prefix' and may be specified multiple times. While this latter
feature isn't necessary to build a Mono cross compiler today, because we don't
use distribution-supplied cross-compilation headers on CI, it does make it
easier to experiment with the offsets tool using arbitrary header layouts. For
example, Debian's arm64 cross-compilation packages scatter useful header files
across `/usr/lib/gcc-cross/aarch64-linux-gnu` and `/usr/aarch64-linux-gnu`.
- Updates the docker image used for arm64 cross-compilation to a newer revision
that includes libclang (see also
https://github.com/dotnet/dotnet-buildtools-prereqs-docker/pull/375).
- Adds some tests that currently fail to compile with Mono LLVM AOT to
issues.targets.
- Adds a Linux_arm64 LLVM AOT job to CI. Nothing particularly fancy is done to
build the Mono LLVM AOT cross compiler; it is built as a step in the same job
that also sends Linux_arm64 tests to Helix.
* Fix various typos
* `occurence`, `occurance` -> `occurrence`
* `accross` -> `across`
* `adddress`, `addresss` -> `address`
* `alignement`, `aligment` -> `alignment`
* Remove `c` from triple c.
* Remove `s` from triple s.
* In palsuite, `Successs` (with triple s) was in commented out
`Trace()` message, removed all commented out `Trace()` calls
from such files.
* Fix invalid markdown in `unix-test-instructions.md`.
* Revert event source change
* Fix link to wasm build instructions
* Update docs/workflow/building/mono/README.md
Co-authored-by: Dan Moseley <danmose@microsoft.com>
Co-authored-by: Dan Moseley <danmose@microsoft.com>
* Move the script runtesttilstable.sh under src/tests
* Update most references to build-test / runtest in the runtime repo
With this change I can't find any remaining orphaned references to
the old script names except for a few superpmi-related scripts
I need to follow up on separately as I'm not too familiar with
their functionality.
Thanks
Tomas
Refactor the PAL test framework to be useable in our CI system, and enable it for testing
The existing PAL tests are problematic in a few ways for our CI.
1. They are large in terms of disk space used per test, this interferes with building them properly, especially as they are part of the product build, and not of the test build
2. While part of the product build, the option to build them was well hidden.
3. The tests are not related to our existing tests, and in particular are not driven from managed xunit wrappers.
The change here has 4 components
1. Reduce the volume of the binaries such that they can be passed from a product build to a test job effectively. This is done by merging all tests which are not strictly dependent on secondary libraries.
- This was done via a tool which parsed and replaced all of the CMakeFiles.txt
- And then manual editing to remove all duplicate global symbols
2. The build flag for building the tests has been exposed as a first class option to build-runtime, as well as through the subset mechanism. As of this change, developers who wish to build the tests should use the clr.paltests subset to build the tests.
3. As the tests do not have normal xunit wrappers, but they *do* have a script which will generate xunit output, they cannot quite be run in the existing helix pathway. Add a separate path for launch the appropriate helix workitem as part of outerloop test runs.
4. A new issue exclusion mechanism has been built. Add exclusions by modifying src/coreclr/src/pal/tests/palsuite/issues.targets
- There are a number of failures in the current test suite that should probably be investigated, but making meaningful changes to the tests should not be part of this change.
Add a subset for compiling only the wasm runtime: `mono.wasmruntime`
This allows us to rebuild the wasm runtime without building the full libraries subset.
Updated documentation with new guidance.
Updated how we build the dotnet.timezones.blat.
* Trim trailing whitespaces
* Match raw with rendered
* Delete extra asterisks and |
* Update ELT Hooks - tail calls.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
I am not very familiar with Unix so I was not aware why I was having below error:
```
/home/jozky/runtime/.dotnet/sdk/5.0.100-preview.8.20362.3/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(379,5): error NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.browser-wasm was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'browser-wasm'. [/home/jozky/runtime/src/libraries/System.IO.FileSystem/tests/System.IO.FileSystem.Tests.csproj]
```
I tried running `dotnet restore --runtime browser-wasm` as suggested by the error but that didn't help.
The correct thing to do was to pass `Release` (with upper case R) to `Configuration` parameter.
cc @safern
Many Linux distributions like to use an extra set of compiler flags (via
`CFLAGS`, `CXXFLAGS` and `LDFLAGS`) to produce builds that are hardened
against vulnerabilities and exploits. The flags sometimes also enable
extra warnings to inform packagers about potential memory issues.
This pach adds support for that to dotnet/runtime.
The obvious method to make this work is to just export the `CFLAGS`,
`CXXFLAGS`, and `LDFLAGS` directly. This, however, enables those flags
during configure-time (aka `cmake` without `--build` too). That means
several cmake configure tests get executed with unexpected compiler
flags. These configure tests can then report incorrect results.
For example, https://bugzilla.redhat.com/show_bug.cgi?id=1712158
demonstrates an issue where the check for `strerror_r` in the runtime
comes to the wrong conclusion because `-Wall` is enabled and a variable
is unused.
A slightly longer fix is to support another set of environment
variables, and use them to set `CFLAGS`, `CXXFLAGS`, `LDFLAGS`, but only
for the invocation of `cmake --build`/`make`.
See #35727 for the complete details.
Fixes#35727
Jose Perez Rodriguez