[master] Update dependencies from dotnet/coreclr

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/coreclr

• Build: 20190530.2
• Date Produced: 5/30/2019 10:50 PM
• Commit: fa8383f
• Branch: refs/heads/master
• Updates:
  • Microsoft.NET.Sdk.IL -> 3.0.0-preview6.19280.2
  • Microsoft.NETCore.ILAsm -> 3.0.0-preview6.19280.2
  • Microsoft.NETCore.Runtime.CoreCLR -> 3.0.0-preview6.19280.2

[dotnet-maestro]

Auto-Merge Status

This pull request has not been merged because Maestro++ is waiting on the following merge policies.

• ❌ All Checks Successful Unsuccessful checks: corefx-ci

[wtgodbe]

Microsoft.DotNet.ApiCompat.targets(143,5): error : MembersMustExist : Member 'System.Environment.TickCount64.get()' does not exist in the reference but it does exist in the implementation.

Due to dotnet/coreclr#24857. I'll fixup the baseline file. CC @stephentoub @jkotas @ericstj

[wtgodbe]

Now the service index for myget is down... great timing. If we can't get this in by noon, it should be covered by dependency flow while we're becoming coherent, so it's not the end of the world.

[stephentoub]

I'll fixup the baseline file.

The fix should be #38063, you can cherry-pick it to verify.

[wtgodbe]

@stephentoub done

[wtgodbe]

@stephentoub failing on NETFX:

[error]System\Net\Http\WinInetProxyHelper.cs(76,25): error CS0117: 'Environment' does not contain a definition for 'TickCount64'

[wtgodbe]

Given that the first half of the change is already in CoreClr, we need to decide on a fix for this now otherwise it will block dependency flow while we're becoming coherent. Either back the change out of CoreClr, fix the above error, or modify the APICompat baseline as a stopgap. @stephentoub do you have a strong preference?

[stephentoub]

Either back the change out of CoreClr, fix the above error, or modify the APICompat baseline as a stopgap.

Let's just fix the above error. Just revert that one file.

[wtgodbe]

This PR has been closed and reopened 12 times, must be some kind of record 🤣

[wtgodbe]

CC @alexperovich @ChadNedzlek @MattGal this is the second time today I've seen a PR that finished test execution in Helix, but the AzDO job never get an indication from Helix that it was done. I remember seeing a similar issue a while back, but I hadn't noticed it again until today. Is this a known thing?

Same thing happened here: #36884

[wtgodbe]

CI failures are unrelated