Reference in box HW intrinsics

[4creators]

Closes PR #19102

cc @tannergooding @jkotas @CarolEidt

[tannergooding]

CC. @bartonjs and @GrabYourPitchforks on the CoreFX System.Security.Cryptography.X509Certificates test failures.

[bartonjs]

It's another "we fixed the test and the product at the same time, but coreclr doesn't pick them up together" problem.

[tannergooding]

@bartonjs, so is this good to merge or should we update the dotnet-maestro-bot commit to a newer version?

[bartonjs]

I don't know how coreclr gets new test binaries. If merging would make all PRs continue to report this problem that'd be bad. If it gets updated tests right after merging then it'd be OK.

But this test failure is torn state, not an indication that something changing in coreclr broke corefx.

[tannergooding]

Do you have a link to the CoreFX side change so I can validate if it is included in the latest dotnet-maestro-bot PR?

[bartonjs]

dotnet/corefx#31269

[tannergooding]

Hmmm. That looks to be included in this PR even....

[tannergooding]

@dotnet-bot test Windows_NT x64 Checked CoreFX Tests please
@dotnet-bot test Ubuntu x64 Checked CoreFX Tests please
@dotnet-bot test OSX10.12 x64 Checked CoreFX Tests please

[4creators]

Failures could mean that we do not use latest CoreFX assemblies due to https://github.com/dotnet/corefx/issues/31395

Essentially what is happening is that NuGet is selecting packages with file version 4.6.0-preview3-xxxxx-xx instead of latest 4.6.0-preview1-xxxxx-xx. This may mean that we are stuck on 1st May, 2018 CoreFX builds during testing.

@tannergooding @bartonjs

[tannergooding]

That doesn't appear to be the case. We are definitely getting the newer CoreFX bits (as evidenced by a33a61f even) and the older bits aren't getting restored at all (looking at all the nuget downloads on a clean VM).

[4creators]

@tannergooding Do you know how to run locally Checked CoreFX Tests. I have problems with getting repro of the failures locally.

[bartonjs]

When a similar thing happened in #18588 the solution was to mark the test in a known issues file (77ee3a8). That led me to believe this is a known class of problem, but really someone who knows how the coreclr/corefx acceptance tests work would have to say if this is really "expected" or not.

[jkotas]

That led me to believe this is a known class of problem, but really someone who knows how the coreclr/corefx acceptance tests work would have to say if this is really "expected"

Yes, this is expected right now. It would be fixed by https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/corefx-testing-framework.md#test-binary-refresh

cc @A-And