Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positive with cxx_lt_to_le #1085

Open
correaa opened this issue Feb 5, 2025 · 1 comment
Open

False positive with cxx_lt_to_le #1085

correaa opened this issue Feb 5, 2025 · 1 comment

Comments

@correaa
Copy link

correaa commented Feb 5, 2025

I find a false positive when Replaced < with <= [cxx_lt_to_le].

This is erroneously reported here: https://gitlab.com/correaa/boost-multi/-/jobs/9043407243#L1886
When I manually do the replacement at that line the test (correctly) fail.

[info] Survived mutants (1/75):
/builds/correaa/boost-multi/include/boost/multi/detail/index_range.hpp:214:112: warning: Survived: Replaced < with <= [cxx_lt_to_le]
	template<class Value> [[nodiscard]] constexpr auto contains(Value const& value) const -> bool { return (value < last_) && (first_ <= value); }

To reproduce I do

$ CXX=clang++-16 cmake .. -DCMAKE_CXX_FLAGS="-O1 -fpass-plugin=/usr/lib/mull-ir-frontend-16 -g -grecord-command-line -fprofile-instr-generate -fcoverage-mapping"
$ cmake --build . --parallel 2
$ cd test
$ ls *.x | xargs -n 1 sh -c 'echo $0 && ((mull-runner-16 --ld-search-path=/usr/lib/x86_64-linux-gnu $0 -test-program=ctest -- -j2 --stop-on-failure) || exit 255)'

This mutation should be covered at least by these tests in test/index_range.cpp, it is almost a textbook example of testing coverage.

		multi::range<int> const irng{5, 12};

		BOOST_TEST( !irng.contains( 4) );
		BOOST_TEST(  irng.contains( 5) );
		BOOST_TEST(  irng.contains( 6) );

		BOOST_TEST(  irng.contains(10) );
		BOOST_TEST(  irng.contains(11) );

		BOOST_TEST( !irng.contains(12) );
		BOOST_TEST( !irng.contains(13) );

Thank you again for the tool

I am using mull-16, I am stuck with 16 because 17 was producing a segfault or something like that (I have to try again).

@correaa
Copy link
Author

correaa commented Feb 6, 2025

It doesn't seem to be deterministic even. I ran the CI again (with no changes), and it passed this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant