Prompted by mono/msbuild#123 :

This includes:

Update to upstream vs16.3 branch
SDK update to track dotnet release/3.0.100-preview8
Roslyn updated to 3.3.0-beta2-19381-14

* Work around remoting1.exe test issue with new Roslyn

…spans in m… (mono#16123)

* [System] Guard against attempting to creating out-of-range spans in macOS FileSystemWatcher

Backport of mono#16049

…elements. (mono#16108)

* Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements.

mono#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.

* Removed unncessary changes

* Unnecessary spaces

* Made the if check a bit more readable

This will allow the interpreter to use System.Reflection.Emit.

Note: There is a small size increase (about 50kb) for an application
built in release mode with the LLVM backend (even if the interpreter
is now used).

Backport of mono#16151

(cherry picked from commit b60aaea)

The loop body uses coop handles, so wrap it in HANDLE_FUNCTION_ENTER/HANDLE_FUNCTION_RETURN

Addresses part of mono#16179

Backport of mono#16184.

Fixes mono#16032

When we switched to corefx File.Copy on unix, the behavior changed where it opened a source and destination stream in order to pass the safe handles to Interop.Sys.CopyFile. This exposed a flaw in our sharing validation rules in MonoIO.Open, which threw an exception in this scenario:

new FileStream("source.txt", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.ReadWrite, 2048, FileOptions.DeleteOnClose);
new FileStream("source.txt", FileMode.Open, FileAccess.Read, FileShare.Read, 2048, FileOptions.None);

Simplified the FileShare check down to:

1. If the caller specifies FileShare.None, then it's an exclusive lock and no
   sharing is allowed.

2. If the caller specifies some other FileShare option, then FileShare.None
    cannot be specified.

…ateStream()`. (mono#16327)

* Add missing `Dispose()` call on error in `MonoTlsStream.CreateStream()`.

* Remove the `finally` block to make it more easy to read.

Backport of mono#16233.

…ono#16392)

The intention of calling `g_file_test (file, G_FILE_TEST_EXISTS)` where file is
the name of a shared library we want to open is to speed up probing for
non-existent libraries.

See mono#12074

The problem is that if file is just a simple "libdl.so" then `dlopen (file)`
doesn't just look for it in the current working directory, it will probe some
other paths too.  (For example on desktop linux you'd also look in all the
directories in LD_LIBRARY_PATH).  So the g_file_test() call is not a robust way
to avoid calling dlopen if the filename is relative.

But it actually broke more things: dotnet/android#3388

When probing for "libdl.so" on Android mono_lookup_pinvoke_call will first try
prepending some paths that it knows about and we end up calling
`dlopen ("/system/lib/libdl.so")` which will fail because Bionic has security
restrictions on what code can dlopen something from /system/lib with an
absolute path.  Eventually mono_lookup_pinvoke_call will go back to trying the
bare "libdl.so" which hits `g_file_test` and returns NULL.

The new code only does the file test if we pass it an absolute path, which
gives Bionic's dlopen a chance to deal with relative paths however it needs to.

Currently, if the process is 32-bit, roslyn tries to determine how much
memory is available. To do that, it tries to pinvoke into GlobalMemoryStatusEx,
which is not supported on mono.

Without it, the compiler server bombs on https://github.com/dotnet/roslyn/blob/0e63260c5afb3fb5b74c357dd250e500172bcd63/src/Compilers/Server/VBCSCompiler/NamedPipeClientConnection.cs#L55-L5

Backport of mono#16405

…#16034. (mono#16424)

Using the CoreCLR version of this line fixed the problem and my investigations
also revealed why.

The `SafePipeHandle` contains a reference to both the Socket as well as the
`SafeSocketHandle`, taking ownership of them.  If there are no additional
references to either of them, so that both are collected in the same GC pass,
their finalizer may be invoked in any order.

If the Socket gets finalized first, it's `SafeSocketHandle` will have a `_mstate`
of 8 (two references) at the beginning of `DangerousReleaseInternal()` - which
will set it to 6 (one reference plus disposed flag).

Then when the `SafePipeHandle` gets collected, it will call `DangerousRelease ()`
on it's `SafeSocketHandle`.  As mentioned above, it's `_mstate` will be 6.
Now we own the handle, so we'll decrease it's reference count by one and set the
`Closed` flag - the new `_mstate` should thus be 3.

However, using

    new_state = (old_state & RefCount_Mask) - RefCount_One;

would set it to 1 - thus effectively clearing the `Disposed' flag.  And since it's
reference count is now also zero, the next finalize pass will then throw.

The CoreCLR version of this class uses

    new_state = old_state - RefCount_One;

which fixes this.

Backport of mono#16244.

* Bump msbuild to track mono-2019-06

.. to get changes from mono/msbuild#130
which tracks dotnet `release/3.0.100-preview9`.

Also, bump Roslyn to 3.3.1-beta3-19421-04 .

* Bump the roslyn reference

…ble shared compilation again (mono#16445)

* [2019-06] bump msbuild to stop disabling shared compilation

* Pull in nuget update for preview 9

…e 11 beta6 (mono#16481)

As of XCode 11 beta6 the MacOSX SDK defines the MAP_32BIT symbol.

This causes the `mono_valloc()` function to try to use the `MAP_32BIT` flag for `mmap()`.

However as mentioned in the comment for the symbol in mman.h it seems to require a special entitlement which isn't available/documented anywhere yet.
This in turn causes the mmap call to fail presumably because we're missing that entitlement.

Instead we now skip setting this flag on Apple platforms to make `mmap()` behave like it did before.

Backport of mono#16441

…cisely. (mono#16489)

* [w32socket] Translate some errno codes to WSA_ errors imprecisely.

These aren't a perfect match, but better than falling into the `default` case
where Mono asserts and crashes.

Addresses part of mono#16024

* [w32error] Add WSA_INVALID_PARAMETER and WSA_INVALID_HANDLE

Backport of mono#16331.

…t feed

(cherry picked from commit 8d42243)

…ss is set

Fixes https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582

Bumps the HttpClient part in mono/corefx at: mono/corefx@ee3acec

The test that would have caught this failure was disabled previously via:
mono@2f41175

(cherry picked from commit 580defd)

Resolves mono#16122

Since we put in the corefx version of GZipStream, it is expected that
our version of DeflateStream actually implements Write+ReadAsyncMemory.

This change does that by just calling the plain WriteAsync & ReadAsync
methods until we decide (or not) to pull in the corefx DeflateStream.

Backport of mono#16523.

* Use the right FileSystemWatcher sources

The corefx code for FileSystemEventArgs has some changes to support
constructing one with a null filename.

Fixes mono#16486

* Remove the mono sources for the newly replaced files

* [csproj] Update project files

…uartz-engine.py (mono#16548)

See mono/bockbuild#116

(cherry picked from commit 309cf1b)

# Conflicts:
#	external/bockbuild

…d5. (mono#16575)

* Bump ikvm to pick up caa8e7f54279a47422626005d228447f5d3670d5.

* [monodis] Add a missing cattr parent case.

Backport of mono#16567.

* Revert "[aot] partial revert of mono#14043 (mono#14135)"

This reverts commit 223e0bd.

* Revert "[aot] change method table generation so that it works for larger assemblies on ARM (mono#14043)"

This reverts commit 9ff3b0d.

…ono#16712

… dotnet 3.0.100-p9 toolset

Add RenamedEvent* to FSW sources from CoreFX

Fixes mono#16486 - This was only partially fixed until now

* [csproj] Update project files

* Add test files which test these code paths on corefx

Backport of mono#16774

…o#16851)

Callers of mono_reflection_create_custom_attr_data_args_noalloc were leaking some of the returned information. Accessed attributes are FixedBufferAttribute and UnmanagedFunctionPointerAttribute.

…r Xamarin.iOS. Fixes xamarin/xamarin-macios#7005. (mono#16896)

This is the equivalent of
xamarin/xamarin-macios@a9abc07,
just for the Mono.frameworks in the mono archive.

Fixes xamarin/xamarin-macios#7005.

We sometimes saw the following build error in Mono SDKs builds on Jenkins:

```
[2019-09-16T01:03:30.709Z] CSC     [xammac] nunit-lite-console.exe
[2019-09-16T01:03:30.709Z] error CS0009: Metadata file '/Users/builder/jenkins/workspace/archive-mono/2019-08/mac/release/mcs/class/lib/xammac/nunitlite.dll' could not be opened -- PE image doesn't contain managed metadata.
```

Taking a closer look we found out that nunit-lite was trying to be built twice for the same profile which caused a race where the file was corrupted.

The reason for this is that the corlib Makefile defines two test assemblies: the normal PROFILE_corlib_test.dll and BinarySerializationOverVersionsTest.dll and
integrating the BinarySerializationOverVersionsTest.dll via the `test-vts` target incorrectly overwrote the `test` target instead of using `test-local`.

Backport of mono#16894.

* [2019-06] Bump msbuild and sdk versions to 3.0.1xx latest

* Bump msbuild again to pull in the build updates

* pull in roslyn-binaries fix

* One more bump

* Fix the roslyn hash

* [msbuild] Bump to pick up a build fix from mono/msbuild#138

* Pull in final update from msbuild of nuget and sdk
NuGet 5.3.0-rtm.6251
Sdk 3.0.100-rc2.19467.3

* Pick up packaging fix in mono/msbuild#141

…mono#16933)

Because the system location isn't world writeable on Catalina.

This was requested by the xamarin-macios team.

(cherry picked from commit 6ad929c)

Requested by xamarin-macios team.

(cherry picked from commit 0a3c9c4)

Xamarin.Mac doesn't need nor use it anymore.

This also removes the last part of the mono archive that required Xcode 9.4.

…) (mono#16851)"

This reverts commit a6b5187.

There is an issue with jumping into DST for some time zones when the incorrect date-time offset is returned for date-time in UTC (which comes from DateTime.Now). The fix is to just check if the incoming date-time is in UTC

Also I added set of tests for some time zones but they verify jumping into DST in general.

Fixes mono#16395

Backport of mono#16430

Contributes to mono#17064

Fixes mono#16803

Backport of mono#17002

Not 1 (TRUE)

…r catch generated by the method called in the owner thread, so we don't need to throw as unhandled exception, we can continue and find the next catch.

Fixes mono#17083

Backport of mono#17106.

* [2019-06] Add drawing type converters to mobile profiles

Needed for dotnet/android#3726

* Bump API snapshot submodule

* [csproj] Update project files

* Bump corefx to get Azure testhost change

See mono/corefx#360

* Update ClientWebSocketTest as well

(cherry picked from commit d457346)

# Conflicts:
#	external/corefx

…etry (mono#17296)

* [merp] Put thread into async context before running summarizer

[merp] Put thread into async context before running summarizer

Followup work for mono#17090

In order to get managed method info for unmanaged stacktraces, we call
`mini_jit_info_table_find_ext` which calls `decode_exception_debug_info` which may
allocate if it's not in async context.

Do the switch in `mono_threads_summarize_execute` so that non-supervising threads
all switch when they run the `sigterm_signal_handler`.  `mono_threads_summarize`
already does it for the supervisor thread.

Fixes mono#17180

Backport of mono#17194.

/cc @lambdageek

* [merp] Don't call install_state_summarizer in EnableMicrosoftTelemetry

install_state_summarizer installs a SIGTERM handler. Unfortunately
sigterm_signal_handler assumes that it will only be called when a crash is
already in progress (it assumes it won't be the supervisor, and so it doesn't
setup the memory for capturing a crash report among other things).

* [merp] Register SIGTERM handler in dump_native_stacktrace

Previously it was installed by EnableMicrosoftTelemetry, which is too early.
Now we get here without a handler installed even when mono_merp_enabled returns true.

This brings us in line with GetDiskFreeSpaceExW on Windows as well as .NET Core.