Custom Query (145 matches)

The pop_and_set_new_owner decrements the wait_count even if no thread was woken up.

void pop_and_set_new_owner( blocking_lock & this ) with( this ) {
	$thread * t = &dropHead( blocked_threads );
	owner = t;
	recursion_count = ( t ? 1 : 0 );
	wait_count--;
	unpark( t );
}

This code doesn't parse unless it's inside a function

#pragma GCC diagnostic push
#pragma GCC diagnostic pop

Known inconsistencies:

• Vector with bits/Containers
• Vector with bits/Sequence

Minimal case

#include <vector.hfa>
#include <bits/sequence.hfa>

Expected: compile succeeds; link fails (no main) Actual: compile fails: Cannot choose between 2 alternatives for back = 0p in ?{}( Sequable & ), where back is ambiguous between datum sq.back (intended) and function declared in vector.hfa (unintended).

Applied case

#include <vector.hfa>             // as in tests/vector.cfa
#include <bits/weakso_locks.hfa>  // represents desire to add this include in fstream.hfa
#include <fstream.hfa>            // as in tests/vector.cfa

(Behaviours are similar)

These prevent Fstream from including Locks (which includes both the above bits) because the Vector test includes Fstream, which produces the problem combination.

Problem comes from bits/x shipping function bodies that declare and refer to the names front/back. When included in a clean context, those names resolve as intended. When included in a context that already has Vector, those names conflict with declarations from Vector, making the lookups ambiguous. The uses that suffer from the ambiguity have assignment/comparison with very generic other arguments, e.g. front != 0p.