libc crate tests do not run (or even compile) on linux targets in CI

@tgross35

#1536 added the ability to mark functions as const, along with a test in https://github.com/rust-lang/libc/blob/42e5708d3c0cfcf68f6ffea45eed7e1732dbd7ec/tests/const_fn.rs. Unfortunately this file is completely dead due to the combination of #[cfg(target_os = "linux")] in it and the behavior introduced in 3eb4a48 which skips building the libc crate when docker: true, which is the case for all linuxes.

This all culminated in the fact that #4105 broke const functions and #4134 failed to fix it in the --no-default-features case. This remains broken.

@tgross35

EDIT: all releases after 0.2.163 which do not contain a fix for this should be yanked.

chore: Pin `libc` to `0.2.163`

Your --no-default-features configuration is not covered, but isn't this test being run by

libc/ci/run.sh

Lines 83 to 92 in 42e5708

    
           cmd="cargo test --target $target ${LIBC_CI_ZBUILD_STD+"-Zbuild-std"}" 
        
           # Run tests in the `libc` crate 
        
           case "$target" in 
        
               # FIXME(android): unit tests fail to start on Android 
        
               # FIXME(s390x): unit tests fail to locate glibc 
        
               *android*) ;; 
        
               *s390x*) ;; 
        
               *) $cmd 
        
           esac

?

No, it is not, because of exec:

libc/ci/run.sh

Line 80 in 42e5708

exec grep -E "^(PASSED)|(test result: ok)" "${CARGO_TARGET_DIR}/out.log"

Were it not for that exec then --no-default-features would be covered:

libc/ci/run.sh

Line 123 in 42e5708

$cmd --no-default-features

The branch with exec would only be executed when QEMU is set, which shouldn't be the case for anything x86 (though a command followed by exit is better style than relying on exec, and that grep seems fragile). I also don't think QEMU is set for any of the qemu-system tests, since those were failing when I added the test branch.

$cmd is not the same at lines 91 and 123, it gains --manifest-path libc-test/Cargo.toml in between. This should probably just be --all on platforms where unit tests can run successfully.

The branch with exec would only be executed when QEMU is set, which shouldn't be the case for anything x86 (though a command followed by exit is better style than relying on exec, and that grep seems fragile). I also don't think QEMU is set for any of the qemu-system tests, since those were failing when I added the test branch.

Yes, I think you're right.

$cmd is not the same at lines 91 and 123, it gains --manifest-path libc-test/Cargo.toml in between. This should probably just be --all on platforms where unit tests can run successfully.

Right, I paged this out. Either that or we shouldn't have tests in the libc crate. The situation today is quite inconsistent. Note that --all is a deprecated alias for --workspace.

fix: Ensure that `const extern fn` is always enabled

Released in 0.2.166 https://github.com/rust-lang/libc/releases/tag/0.2.166

Navigation Menu

Repository navigation

`libc` crate tests do not run (or even compile) on linux targets in CI #4149

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	cmd="cargo test --target $target ${LIBC_CI_ZBUILD_STD+"-Zbuild-std"}"

	# Run tests in the `libc` crate
	case "$target" in
	# FIXME(android): unit tests fail to start on Android
	# FIXME(s390x): unit tests fail to locate glibc
	android) ;;
	s390x) ;;
	*) $cmd
	esac

libc crate tests do not run (or even compile) on linux targets in CI #4149

Description

Activity

tgross35 commented on Nov 26, 2024

tamird commented on Nov 26, 2024

tgross35 commented on Nov 26, 2024

tamird commented on Nov 26, 2024

tgross35 commented on Nov 26, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`libc` crate tests do not run (or even compile) on linux targets in CI #4149