Well… all the tests except the Peter Ellis Jones tests.
Pass around whole EnPassant types instead of pulling out just the e.p. square.
Make sure that Castling moves have their target and origin squares populated.
Add a color field to the Castle move style to make this possible.
Replace Position's en_passant_target_square() and en_passant_capture_square()
with a single en_passant() method that returns a new EnPassant struct that has
the target and capture squares for the en passant move.
Build Position::sight_of_piece() and ::is_king_in_check() for cfg(test) only.
Expand the doc comment for ::king_danger() slightly.
Remove an unused Rank import.
# Conflicts:
# position/src/position/position.rs
The pawn move generator only generated pushes for white pawns.
The is_king_in_check returned an inverted flag.
MoveSet needed a couple more validation methods: can_move_to_square and can_castle.
The MakeMoveBuilder also needed a little more move validation using the above methods.
Use CheckingPieces to determine which and how many pieces check the king.
- If there are no checks, proceed with move generation as normal.
- If there is one checking piece, calculate push and capture masks and use those
to generate legal moves.
- If there are more than one checking pieces, the only legal moves are king
moves. Indicate this by setting the push and capture masks to EMPTY.
Position::default specifies the defaults for all field. Then, ::new() and
::starting() can use ..Default::default() in their implementations to avoid
having to specify empty values for all the internal structures.
Add a field to MoveSet called special that flags special moves that should be
generated in the iter() method. This field is a u8. It only tracks castles in
the first and second bits (kingside and queenside, respectively). The move iterator
chains two maps over Option<()> that produce the kingside and queenside castle
moves.
With that done, finish the implementation of Position::player_can_castle by
adding checks for whether the squares between the rook and king are clear, and
that the king would not pass through a check. This is done with BitBoards!
Finally, implement some logic in PositionBuilder that updates the position's
castling flags based on the positions of king and rooks.
Supporting changes:
- Add Color:ALL and iterate on that slice
- Add Castle::ALL and iterator on that slice
- Add a CastlingParameters struct that contains BitBoard properties that describe
squares that should be clear of pieces and squares that should not be attacked.
