Rust test #20651

filnet · 2024-04-16T12:44:03Z

No description provided.

filnet · 2024-04-16T12:50:56Z

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 · 2024-04-16T13:08:09Z

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 · 2024-04-16T13:12:48Z

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 · 2024-04-16T13:36:22Z

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 · 2024-04-16T13:37:09Z

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 · 2024-04-16T18:01:28Z

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)

mingw-w64-rust/PKGBUILD

filnet · 2024-04-16T22:52:41Z

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 · 2024-04-17T16:21:19Z

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 · 2024-04-17T16:46:00Z

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

ognevny · 2024-04-17T17:44:48Z

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

maybe a separate job for build+check?

jeremyd2019 · 2024-04-17T18:23:51Z

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 · 2024-04-17T18:29:45Z

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 · 2024-04-17T19:17:04Z

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 · 2024-04-17T20:15:38Z

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 · 2024-04-17T22:53:09Z

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 · 2024-04-17T23:52:03Z

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 · 2024-04-18T00:36:02Z

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

mingw-w64-rust/PKGBUILD

filnet · 2024-04-18T08:38:44Z

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 · 2024-04-18T11:57:37Z

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 · 2024-04-18T17:06:03Z

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 · 2024-04-18T17:33:37Z

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 · 2024-04-18T17:51:05Z

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

jeremyd2019 · 2024-04-18T17:58:21Z

Interesting, I'll try that next

filnet · 2024-04-18T18:03:02Z

And rust-lang/rust#111894

jeremyd2019 · 2024-04-18T18:06:12Z

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 · 2024-06-12T21:22:35Z

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 · 2024-06-12T22:18:37Z

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 · 2024-06-12T23:30:52Z

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 · 2024-06-13T01:14:26Z

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 · 2024-06-13T05:23:02Z

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 · 2024-06-13T10:02:17Z

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

filnet · 2024-06-13T10:09:17Z

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 · 2024-06-13T16:18:35Z

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 · 2024-06-13T16:55:32Z

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 · 2024-06-13T20:31:09Z

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 · 2024-06-13T20:52:41Z

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

The tests\ui\issues\issue-2214.rs test fails with undefined reference to `__sinl_internal' and other math functions. Mateusz Mikuła analyzed the issue and found that the root cause is this change in mingw-w64: mingw-w64/mingw-w64@a64c1f4 The error happens because Rust pulls in lgamma from libmingwex.a, which pulls in sin from libmsvcrt.a, which in turn tries to pull in __sinl_internal from libmingwex.a and fails because of how Rust links MinGW libs. The proposed fix was to add an extra "-lmingwex" after the second "-lmsvcrt" in https://github.com/rust-lang/rust/blob/aa6a697a1c75b0aa06954136f7641706edadc2be/compiler/rustc_target/src/spec/base/windows_gnu.rs#L30.

This matches what was already being done for the split docs package.

* skip debuginfo tests on all platforms * skip tests that fail on CLANG* * enable no-fail-fast * checkdepends on gcc-compat package for clang Because of the bootstrapping hack, at least one test tries to use $TRIPLE-gcc to link rather than $TRIPLE-clang. The easiest workaround seems to be to ensure there is an alias to clang with that name.

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

by default makepkg is run with the --nocheck option this can be overriden per package by adding the package name to ./.ci/ci-check-list.txt

filnet · 2024-06-14T14:30:16Z

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 · 2024-06-14T17:10:36Z

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 · 2024-06-15T04:38:38Z

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 · 2024-06-15T14:03:45Z

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 · 2024-06-15T16:45:33Z

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

mati865 · 2024-06-16T14:57:25Z

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 · 2024-06-16T16:24:37Z

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 · 2024-06-16T16:28:41Z

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

Kreijstal · 2024-06-16T19:06:24Z

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

filnet mentioned this pull request Apr 16, 2024

rust: update to 1.77.1 #20397

Merged

mati865 reviewed Apr 16, 2024

View reviewed changes

mingw-w64-rust/PKGBUILD Outdated Show resolved Hide resolved

filnet force-pushed the rust_test branch from 83799d7 to e0cdd2e Compare April 17, 2024 12:35

jeremyd2019 reviewed Apr 18, 2024

View reviewed changes

mingw-w64-rust/PKGBUILD Outdated Show resolved Hide resolved

filnet force-pushed the rust_test branch from e0cdd2e to 2ac38a2 Compare April 18, 2024 08:52

filnet force-pushed the rust_test branch from 199da68 to ffdae80 Compare June 12, 2024 22:35

filnet closed this Jun 13, 2024

filnet reopened this Jun 13, 2024

filnet and others added 4 commits June 13, 2024 23:51

rust: update to 1.79.0

8532afd

rust: move split src files away in build function

0ab2b78

This matches what was already being done for the split docs package.

filnet force-pushed the rust_test branch from ffdae80 to 061214d Compare June 14, 2024 09:38

filnet added 2 commits June 14, 2024 11:40

skip non-unicode-in-incremental-dir test

7e53ace

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

ci: add opt-in check list

061214d

by default makepkg is run with the --nocheck option this can be overriden per package by adding the package name to ./.ci/ci-check-list.txt

Rust test #20651

Are you sure you want to change the base?

Rust test #20651

Conversation

filnet commented Apr 16, 2024

filnet commented Apr 16, 2024

filnet commented Apr 16, 2024

filnet commented Apr 16, 2024

ognevny commented Apr 16, 2024

ognevny commented Apr 16, 2024

jeremyd2019 commented Apr 16, 2024

filnet commented Apr 16, 2024

filnet commented Apr 17, 2024 • edited Loading

filnet commented Apr 17, 2024

ognevny commented Apr 17, 2024

jeremyd2019 commented Apr 17, 2024

ognevny commented Apr 17, 2024

jeremyd2019 commented Apr 17, 2024 • edited Loading

filnet commented Apr 17, 2024 • edited Loading

jeremyd2019 commented Apr 17, 2024 • edited Loading

mati865 commented Apr 17, 2024

jeremyd2019 commented Apr 18, 2024

filnet commented Apr 18, 2024

Kreijstal commented Apr 18, 2024

jeremyd2019 commented Apr 18, 2024 • edited Loading

filnet commented Apr 18, 2024 • edited Loading

filnet commented Apr 18, 2024

jeremyd2019 commented Apr 18, 2024

filnet commented Apr 18, 2024

jeremyd2019 commented Apr 18, 2024

jeremyd2019 commented Jun 12, 2024

filnet commented Jun 12, 2024

jeremyd2019 commented Jun 12, 2024

filnet commented Jun 13, 2024 • edited Loading

jeremyd2019 commented Jun 13, 2024 • edited Loading

filnet commented Jun 13, 2024

filnet commented Jun 13, 2024 • edited Loading

mati865 commented Jun 13, 2024

jeremyd2019 commented Jun 13, 2024

filnet commented Jun 13, 2024

jeremyd2019 commented Jun 13, 2024 • edited Loading

filnet commented Jun 14, 2024

jeremyd2019 commented Jun 14, 2024

jeremyd2019 commented Jun 15, 2024 • edited Loading

filnet commented Jun 15, 2024

filnet commented Jun 15, 2024

mati865 commented Jun 16, 2024

Kreijstal commented Jun 16, 2024 • edited Loading

mati865 commented Jun 16, 2024 • edited Loading

Kreijstal commented Jun 16, 2024

filnet commented Apr 17, 2024 •

edited

Loading

jeremyd2019 commented Apr 17, 2024 •

edited

Loading

filnet commented Apr 17, 2024 •

edited

Loading

jeremyd2019 commented Apr 17, 2024 •

edited

Loading

jeremyd2019 commented Apr 18, 2024 •

edited

Loading

filnet commented Apr 18, 2024 •

edited

Loading

filnet commented Jun 13, 2024 •

edited

Loading

jeremyd2019 commented Jun 13, 2024 •

edited

Loading

filnet commented Jun 13, 2024 •

edited

Loading

jeremyd2019 commented Jun 13, 2024 •

edited

Loading

jeremyd2019 commented Jun 15, 2024 •

edited

Loading

Kreijstal commented Jun 16, 2024 •

edited

Loading

mati865 commented Jun 16, 2024 •

edited

Loading