Use u64::MIN and u64::MAX to define the empty and full bitboards
Write From<Square> as `1u64 << sq as u32`
Write a doc test for BitBoard::is_single_square()
Make library::RANKS and library::FILES pub(crate) instead of pub(super)
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.
Add an origin square argument to its one method ::ray_to_square(). Pushing this
implementation down a layer means I don't have to care about the color of the
piece.
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.
This trait declares ray_to_square() which should return a BitBoard representing
a ray from a Square to another Square. The ray should include the target Square.
PlacedPiece implements this trait.
Add two small BitBoard slices that represent kingside and queenside squares per
color.
Add doc comments to DARK_SQUARES and LIGHT_SQUARES.
Add getters on BitBoard for getting a boardside bitboard.
Clean up imports. Import the whole library module and refer to library things in
BitBoard by path.
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.
