Rust test

[filnet]

No description provided.

[filnet]

Posted a message about the breaking change in mingw-w64: https://sourceforge.net/p/mingw-w64/mailman/message/58760949/

For now the fix is only for MINGW64? Should it also target MINGW32 ?

I will share the run-make tests failure here.

[filnet]

Where do we pull in mingw-w64?

There is https://github.com/msys2/MSYS2-packages/blob/master/mingw-w64-cross-headers/PKGBUILD#L19 but it uses version 11.0.1 which does not contain the breaking change.

[filnet]

More questions...

Cheks are disabled in CI : https://github.com/msys2/MINGW-packages/blob/master/.ci/ci-build.sh#L136

What is the reason and would it make sense to enable them for specific packages like Rust ?

[ognevny]

More questions...

Cheks are disabled in CI : https://github.com/msys2/MINGW-packages/blob/master/.ci/ci-build.sh#L136

What is the reason and would it make sense to enable them for specific packages like Rust ?

they are disable as they can run very long or unexpectedly fail (which stops the whole build)

[ognevny]

Where do we pull in mingw-w64?

There is https://github.com/msys2/MSYS2-packages/blob/master/mingw-w64-cross-headers/PKGBUILD#L19 but it uses version 11.0.1 which does not contain the breaking change.

wrong package, actually https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-headers-git is used for non-msys environments

[jeremyd2019]

I'm not sure about bothering with .gitignore - I don't remember seeing other packages doing that. Also, it might be a good idea to switch to the official upstream commits now that they work (https://github.com/rust-lang/compiler-builtins/commit/d8ab794ed61e2c7c0750f57332a680d5aa8db48c.patch and https://github.com/rust-lang/compiler-builtins/commit/3f47913bc6414bab4254d49f9f6e7238fecace69.patch)

[filnet]

I also had errors in run-make/doctests-keep-binaries but after enabling the doc and compiler doc they worked...
Will report it upstream if confirmed.

[filnet]

I also had errors in run-make/doctests-keep-binaries but after enabling the doc and compiler doc they worked... Will report it upstream if confirmed.

I can't reproduce anymore...

So I am all set with this PR.

[filnet]

Would be great to run the check in CI. I am only testing MINGW64 atm.

[ognevny]

Would be great to run the check in CI. I am only testing MINGW64 atm.

maybe a separate job for build+check?

[jeremyd2019]

Would be great to run the check in CI. I am only testing MINGW64 atm.

maybe a separate job for build+check?

Might be a worthwhile "discussion" or separate issue, but in the past having checks that failed but were 'expected' to fail (even if not configured as required for merging) would confuse contributors, and setting up the job so that the job itself would not fail when the step failed would make it too hard for people who cared to notice that it had failed.

[ognevny]

Would be great to run the check in CI. I am only testing MINGW64 atm.

maybe a separate job for build+check?

Might be a worthwhile "discussion" or separate issue, but in the past having checks that failed but were 'expected' to fail (even if not configured as required for merging) would confuse contributors, and setting up the job so that the job itself would not fail when the step failed would make it too hard for people who cared to notice that it had failed.

can this job be run by manual requests only?

[jeremyd2019]

can this job be run by manual requests only?

We could have a workflow_dispatch triggered workflow, but a) only users with rights to the repository could run it (others could enable and run it in their forks, but they could do that now by just taking --nocheck out of the script in their fork). and more importantly, b) it wouldn't be associated with a pull request, so the git magic that determines what packages were modified so it knows what to build wouldn't be able to work. packages to check would have to be specified manually on the workflow_dispatch input.

I was just thinking, maybe some sort of hack such as some magic name of the head branch of the pull request could be a way for the creator of the pull request to signal that they want check to run? I don't know if there is any other convenient user-controlled flag that would be available to filter on. Maybe a label on the pull request, but I don't know that non-privileged users can label their own pull requests.

[filnet]

I was not suggesting to check all packages but only selected ones.

We could do something similar to what is done for installing or not.
See https://github.com/msys2/MINGW-packages/blob/master/.ci/ci-build.sh#L147.
Note that ci-dont-install-list.txt is currently empty. So this feature is not used.

Alternatively we could move the rust tests to the build phase.

[jeremyd2019]

I did a CI run on my fork with --nocheck removed. MINGW64 and UCRT64 are still running seem to have succeeded, but everything else failed:
https://github.com/jeremyd2019/MINGW-packages/actions/runs/8728491385

MINGW32 seems to have failed because of the -lmingwex issue. CLANG64 failed on

  failures:
      [ui] tests\ui\rfcs\rfc-2627-raw-dylib\dlltool-failed.rs
      [ui] tests\ui\rfcs\rfc-2627-raw-dylib\invalid-dlltool.rs

CLANG32 failed with fatal runtime error: failed to initiate panic, error 5 I don't know what that's about.

It wouldn't surprise me a bit if some tests are screwed on CLANG32/CLANG64 due to the clang subsystem patch (that is, lying about the target being -gnu instead of -gnullvm)

[mati865]

CLANG64 failed on

  failures:
      [ui] tests\ui\rfcs\rfc-2627-raw-dylib\dlltool-failed.rs
      [ui] tests\ui\rfcs\rfc-2627-raw-dylib\invalid-dlltool.rs

IIRC that's indeed because of using gnu triple.

CLANG32 failed with fatal runtime error: failed to initiate panic, error 5 I don't know what that's about.

Hard to tell, but likely caused by the same reason.

[jeremyd2019]

Same failure on CLANG64 with gnullvm host/target

failures:
    [ui] tests\ui\rfcs\rfc-2627-raw-dylib\dlltool-failed.rs
    [ui] tests\ui\rfcs\rfc-2627-raw-dylib\invalid-dlltool.rs

test result: FAILED. 15875 passed; 2 failed; 194 ignored; 0 measured; 0 filtered out; finished in 225.75s

Some tests failed in compiletest suite=ui mode=ui host=x86_64-pc-windows-gnullvm target=x86_64-pc-windows-gnullvm

[filnet]

About the -lmingwex issue, Martin Storsjö said:

We have a fair bit of these kinds of circular dependencies between
libmingwex.a and libmsvcr*.a. And we'll probably get more of them, not
less, as we specialize some of our helper routines into different versions
for different CRTs (like this change).

So therefore, breakage of this kind is indeed not surprising, when linking
with ld.bfd, if the libs aren't specified repeatedly.

When driving linking with GCC and Clang, the linker is already invoked
with multiple "-lmsvcrt -lmingwex [..] -lmsvcrt -lmingwex". There are also
other similar issues that we've had to fix by adding more of these
duplicate linker options, see e.g.
gcc-mirror/gcc@850533a.

This is not an issue with lld, because it scans for symbols in all loaded
libraries, not in the strict sequential manner that ld.bfd does.

Alternatively, instead of just repeating these linker options over and
over, we could consider to add --start-group --end-group around these
linker options, in GCC, Clang and Rust, which would allow resolving any of
the dependencies in these libraries among themselves. Clang already passes
this, see e.g.
https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/MinGW.cpp#L277-L348,
but it only seems to do this when intending to link statically. Perhaps
this should be done unconditionally - this is already done for some
targets, see e.g.
https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/NaCl.cpp#L146-L147.

// Martin

The change that is mentioned is this one : mingw-w64/mingw-w64@a64c1f4

[Kreijstal]

Would be great to run the check in CI. I am only testing MINGW64 atm.

maybe a separate job for build+check?

Might be a worthwhile "discussion" or separate issue, but in the past having checks that failed but were 'expected' to fail (even if not configured as required for merging) would confuse contributors, and setting up the job so that the job itself would not fail when the step failed would make it too hard for people who cared to notice that it had failed.

if the tests are expected to fail, it should pass, not fail, should it not?

[jeremyd2019]

Regarding the dlltool tests on CLANG64: I suspect upstream they should have // ignore-llvm added to ignore the llvm abi (yeah, that's kind of an odd thing to write, but the syntax is ignore-<abi> and the abi is llvm). What they have now is only-gnu (which both gnu and gnullvm satisfy the env being gnu) and needs-dlltool (which appears to mean: has dlltool on the PATH, which we do both in /clang64/bin/ and in /usr/bin because msys binutils is installed too IIRC).

Unfortunately that doesn't help in our case where the target is a lie. I'm not sure how to work that out for this package - is there some way to specify a list of specific tests to ignore?

[filnet]

Unfortunately that doesn't help in our case where the target is a lie. I'm not sure how to work that out for this package - is there some way to specify a list of specific tests to ignore?

There is documentation about testing : https://rustc-dev-guide.rust-lang.org/tests/running.html
It has examples on how to run specific tests but it does not discuss --skip.
I tried to skip specific tests but failed to do so. You might be luckier.

[filnet]

Skipping tests is dicussed here : rust-lang/rust#123342 (review)
I did not try with the extra --.

[jeremyd2019]

Interesting, I'll try that next

[filnet]

And rust-lang/rust#111894

[jeremyd2019]

in the past having checks that failed but were 'expected' to fail (even if not configured as required for merging) would confuse contributors
if the tests are expected to fail, it should pass, not fail, should it not?

Sorry, I meant tests that may pass or fail, we don't know, but won't generally hold up merging either way. But I think this would be better in a separate discussion.

[jeremyd2019]

Oops, I led you astray - looks like those backtrace commits are included in rust 1.79.0 those 2 patches and their application can be removed now.

[filnet]

Oops, I led you astray - looks like those backtrace commits are included in rust 1.79.0 those 2 patches and their application can be removed now.

No problems... Does it explain some of the test failures ?

I too had a slightly hard time confirming if some of the commit I removed were really in 1.79.0.
Some commits still mentioned master only as target.
I guess the whole branching/merging/whatever process at Rust obscures things a bit.

[jeremyd2019]

Oops, I led you astray - looks like those backtrace commits are included in rust 1.79.0 those 2 patches and their application can be removed now.

No problems... Does it explain some of the test failures ?

Unfortunately, no. This failed immediately when I was trying to build for clangarm64, with the patches failing to apply. These patches were only applied on arm64 anyway.

[filnet]

The directory deletion error happens after the Rust build.

[install] mingw-w64-clang-x86_64-rust
[meta-diff] mingw-w64-clang-x86_64-rust
[file-diff] mingw-w64-clang-x86_64-rust
[runtime-dependencies] mingw-w64-clang-x86_64-rust
[uninstall] mingw-w64-clang-x86_64-rust
[install] mingw-w64-clang-x86_64-rust-docs
[meta-diff] mingw-w64-clang-x86_64-rust-docs
[file-diff] mingw-w64-clang-x86_64-rust-docs
[runtime-dependencies] mingw-w64-clang-x86_64-rust-docs
[uninstall] mingw-w64-clang-x86_64-rust-docs
[install] mingw-w64-clang-x86_64-rust-src
[meta-diff] mingw-w64-clang-x86_64-rust-src
[file-diff] mingw-w64-clang-x86_64-rust-src
[runtime-dependencies] mingw-w64-clang-x86_64-rust-src
[uninstall] mingw-w64-clang-x86_64-rust-src
rm: cannot remove 'B/src/CLANG64/build/x86_64-pc-windows-gnu/test/run-make/non-unicode-in-incremental-dir/non-unicode-in-incremental-dir/incr-dir/foo-33hheqpmhfum1': Directory not empty

Could be related to the new rust-src package. This literally is the 2nd build that has it.

[jeremyd2019]

I don't think so, it comes from a "test" directory, so it is probably just an issue cleaning up after the test. I've hit similar issues on CLANGARM64 which I assumed to be MAX_PATH issues.

rm : Cannot remove item C:\_\B\src\CLANGARM64\build\aarch64-pc-windows-gnullvm\test\codegen-units\partitioning\extern-drop-glue\extern-drop-glue.inc\cgu_extern_drop_glue-1mr9ecltxqxd3\s-gx2av7fjup-fxu81p-6y0v4mk5dfqo38y0mxel17ucj\cgu_extern_drop_glue.6b53ba1e25fed067-fallback.cgu.pre-lto.bc: Could not find a part of the path 'cgu_extern_drop_glue.6b53ba1e25fed067-fallback.cgu.pre-lto.bc'.

That's from the "cleanup runner" powershell snippet trying to delete C:\_

[filnet]

So we can't do much about it except asking Rust to shorten some of its paths.

[filnet]

Found the rm -rf B : https://github.com/msys2/MINGW-packages/blob/master/.ci/ci-build.sh#L178

Which makes the error strange...

rm: cannot remove 'B/src/CLANG64/build/x86_64-pc-windows-gnu/test/run-make/non-unicode-in-incremental-dir/non-unicode-in-incremental-dir/incr-dir/foo-33hheqpmhfum1': Directory not empty

The path does not look that long.
Why is the directory not empty at this stage ? I would expect a failure at removing the content of the directory.
Is something else writing there in // ?

We could list the content of B/ after the rm to get some insight.

EDIT:

There is a new test that tries to create directories with non unicode path.
See https://github.com/rust-lang/rust/blob/921645c737f1d6d107a0a10ca5ee129d364dcd7a/tests/run-make/non-unicode-in-incremental-dir/rmake.rs.
Looks like the test succeeds but then cleanup fails.

[mati865]

C:_\B\src\CLANGARM64\build\aarch64-pc-windows-gnullvm\test\codegen-units\partitioning\extern-drop-glue\extern-drop-glue.inc\cgu_extern_drop_glue-1mr9ecltxqxd3\s-gx2av7fjup-fxu81p-6y0v4mk5dfqo38y0mxel17ucj\cgu_extern_drop_glue.6b53ba1e25fed067-fallback.cgu.pre-lto.bc

It's needlessly long (probably that was the easiest way), might be worth filing a new issue upstream.

There is a new test that tries to create directories with non unicode path.

Sounds plausible, there were many issues with non unicode paths in MSYS2.

[jeremyd2019]

Sounds plausible, there were many issues with non unicode paths in MSYS2.

If we can figure out what that path is (including whatever non-unicode characters) and reproduce it simply (without rust test suite), we could see if it's a bug in msys2-runtime or cygwin.

[filnet]

If we can figure out what that path is (including whatever non-unicode characters) and reproduce it simply (without rust test suite), we could see if it's a bug in msys2-runtime or cygwin.

It's there : https://github.com/rust-lang/rust/blob/921645c737f1d6d107a0a10ca5ee129d364dcd7a/tests/run-make/non-unicode-in-incremental-dir/rmake.rs.

let non_unicode: std::ffi::OsString = std::os::windows::ffi::OsStringExt::from_wide(&[0xD800]);

The non_unicode string is later used to create a directory.

[jeremyd2019]

Yep, breaks for me:

mkdir -p foo/$'\uD800'
rm -rf foo
rm: cannot remove 'foo': Directory not empty

https://cygwin.com/pipermail/cygwin/2024-June/256111.html

[filnet]

I don't understant the MINGW64 error:

1 command(s) did not execute successfully:

  - "C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage0-tools-bin\\compiletest.exe" "--compile-lib-path" "C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\bin" "--run-lib-path" "C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "--rustc-path" "C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\bin\\rustc.exe" "--src-base" "C:\\_\\B\\src\\rustc-1.79.0-src\\tests\\crashes" "--build-base" "C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\crashes" "--sysroot-base" "C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2" "--stage-id" "stage2-x86_64-pc-windows-gnu" "--suite" "crashes" "--mode" "crashes" "--target" "x86_64-pc-windows-gnu" "--host" "x86_64-pc-windows-gnu" "--llvm-filecheck" "D:/M/msys64/mingw64/bin\\FileCheck.exe" "--optimize-tests" "--host-rustcflags" "-Crpath" "--host-rustcflags" "-Cdebuginfo=0" "--host-rustcflags" "-Lnative=C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\native\\rust-test-helpers" "--target-rustcflags" "-Crpath" "--target-rustcflags" "-Cdebuginfo=0" "--target-rustcflags" "-Lnative=C:\\_\\B\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\native\\rust-test-helpers" "--python" "D:/M/msys64/mingw64/bin/python" "--lldb-version" "lldb version 18.1.6\n" "--lldb-python-dir" "D:\\M\\msys64\\mingw64\\lib\\python3.11\\site-packages" "--skip" "tests\\debuginfo" "--skip" "tests\\run-make\\non-unicode-in-incremental-dir" "--json" "--llvm-version" "18.1.6" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen codegentypes core coroutines coverage debuginfobtf debuginfocodeview debuginfodwarf debuginfogsym debuginfologicalview debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker dwarflinkerclassic dwarflinkerparallel dwp engine executionengine extensions filecheck frontenddriver frontendhlsl frontendoffloading frontendopenacc frontendopenmp fuzzercli fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo hipstdpar instcombine instrumentation interfacestub interpreter ipo irprinter irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker loongarch loongarchasmparser loongarchcodegen loongarchdesc loongarchdisassembler loongarchinfo lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts objcopy object objectyaml option orcdebugging orcjit orcshared orctargetprocess passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvtargetmca runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target targetparser textapi textapibinaryreader transformutils ve veasmparser vecodegen vectorize vedesc vedisassembler veinfo webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86targetmca xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/local/tmp/work" "--android-cross-path" "" "--channel" "stable" "--git-hash" "--git-repository" "rust-lang/rust" "--nightly-branch" "master" "--color" "always"

Build completed unsuccessfully in 1:02:59
==> ERROR: A failure occurred in check().
    Aborting...

It just says that some command did not execute successfully without giving any error message.
How am I supposed to work on this ?

[jeremyd2019]

That's the downside of --no-fail-fast IMHO. Buried in that blob of command line is the section of the tests that failed: "--suite" "crashes" "--mode" "crashes". Find the section of the output for that test (Testing stage2 compiletest suite=crashes mode=crashes (x86_64-pc-windows-gnu)), expand it, and see the real error:

failures:
  
  ---- [crashes] tests\crashes\23707.rs stdout ----
  
  error: test no longer crashes/triggers ICE! Please give it a mearningful name, add a doc-comment to the start of the test explaining why it exists and move it to tests/ui or wherever you see fit.
  thread '[crashes] tests\crashes\23707.rs' panicked at src\tools\compiletest\src\runtest.rs:2804:9:
  fatal error
  stack backtrace:
     0: rust_begin_unwind
     1: core::panicking::panic_fmt
     2: <compiletest::runtest::TestCx>::fatal
     3: <compiletest::runtest::TestCx>::run_revision
     4: compiletest::runtest::run
     5: <compiletest::make_test_closure::{closure#0} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
  
  
  failures:
      [crashes] tests\crashes\23707.rs
  
  test result: FAILED. 217 passed; 1 failed; 1 ignored; 0 measured; 0 filtered out; finished in 8.63s

[jeremyd2019]

Yep, breaks for me:

mkdir -p foo/$'\uD800'
rm -rf foo
rm: cannot remove 'foo': Directory not empty

https://cygwin.com/pipermail/cygwin/2024-June/256111.html

As a followup, that simple testcase succeeds on cygwin 3.4.10, 3.5.1, and a couple of 3.6.0 test versions (the oldest and most recent), so I figure it's a pretty safe bet that it was some sort of regression that has already been fixed upstream. Hopefully 3.5.4 will include the fix (ie, hopefully it's something that's already on the 3.5 branch).

UPDATE: today they all fail. Don't know what is going on

[filnet]

A bunch of crash tests were added in 1.79.0 including the one that fails (to crash).
See rust-lang/rust@7d826ae#diff-7f7fc810195091153bec59a2e4b5f4d0622a4d51bf7f3d4eff4211d5140b7c3d

A later commit limited some the crash tests to only run on x86_64 and/or not on windows
See rust-lang/rust@2ce487c#diff-7f7fc810195091153bec59a2e4b5f4d0622a4d51bf7f3d4eff4211d5140b7c3d

[filnet]

How do you fix something that is supposed to crash but does not ?

[mati865]

We could probably skip all the tests from that directory as they aren't very useful for us. Upstream probably uses them to ease issue management.

[Kreijstal]

How do you fix something that is supposed to crash but does not ?

pull request telling them that there is no bug on windows :)

[mati865]

The platform is irrelevant here, also you can see the compiler crashed as expected with CLANG64 env.

[Kreijstal]

The platform is irrelevant here, also you can see the compiler crashed as expected with CLANG64 env.

ah maybe it is a llvm bug? Anyway it seems some rust tests aren't really tests but more like documentation of bugs