Reorganize castling rights API on Board into methods named according to
conventions applied to other API.
Board::has_castling_right
Board::has_castling_right_active
Board::has_castling_right_unwrapped
These all check if a color has the right to castle on a particular side
(wing) of the board. The first takes an Option<Color>, the latter two
operate on bare Colors: the active color, or an explicit Color.
Board::grant_castling_right
Board::grant_castling_right_active
Board::grant_castling_right_unwrapped
Grant castling rights to a color. Color arguments follow the pattern above.
Board::revoke_castling_right
Board::revoke_castling_right_active
Board::revoke_castling_right_unwrapped
Revoke castling rights from a color. Color arguments follow the pattern
above.
The latter two groups of methods take a new CastleRightsOption type that
specifies either a single Wing or All.
Rework the implementation of CastleRights to take a CastleRightsOption. Update
the unit tests and make sure everything builds.
There was a bug in the code that revokes castling rights after a king move where
it revoked the rights for *all* players, rather than just the current player.
Fix it.
When the King moves, revoke all rights for the moving player. When the rook moves,
revoke castling rights for that side of the board, if it's moving off its starting
square.
Board::color_has_castling_right takes an Option<Color> which it unwraps. With that
unwrapped Color, it can call…
Board::color_has_castling_right_unwrapped, which performs the evaluation with a
non-Option Color.
Clean up some imports.
UCI uses a move format it calls "long algebraic". They look like either "e2e4"
for a regular move, or "h7h8q" for a promotion. Implement parsing these move
strings as a two step process. First define an AlgebraicMoveComponents struct
in the moves crate that implements FromStr. This struct reads out an origin
square, a target square, and an optional promotion shape from a string. Then,
implement a pair of methods on Position that take the move components struct
and return a fully encoded Move struct with them.
This process is required because the algebraic string is not enough by itself to
know what kind of move was made. The current position is required to understand
that.
Implement Shape::is_promotable().
Add a NULL move to the Move struct. I'm not sure what this is used for yet, but
the UCI spec specifically calls out a string that encodes a null move, so I added
it. It may end up being unused!
Do a little bit of cleanup in the core crate as well. Use deeper imports (import
std::fmt instead of requring the fully qualified type path) and remove some
unnecessary From implementations.
This commit is also the first instance (I think) of defining an errors module
in lib.rs for the core crate that holds the various error types the crate exports.
The move I observed in my testing was a castling move, which doesn't set target
and origin squares because those are provided by the castling parameters struct
from the board crate.
Fix the missing squares on castle moves by looking up castling parameters and
populating them. This requires Move::castle() to take a Color in addition to the
Wing. Update all the call sites.
This thing isn't used by any of the "modern" code I've written. It was difficult
to write, but kinda neat architecturally. It made a lot of invalid configurations
of moves into build-time errors. Anyway…
Remove several of the tests that relied on it, but that hadn't been updated to
use the newer code either.
Instead of generating e.p. moves in a separate pass, check whether each capture
move (left and right) targets the en passant square. If so, yield an e.p. capture
otherwise just a regular capture.
En passant state should be cleared after any move that isn't a double push.
To support this fix, rename advance_clocks to advance_board_state and let it take
an Option<Square>. Every supporting make_move method calls this method to update
board state when the make is done. So this is the ideal place to also update
e.p. state.
Remove the <n> argument from this method. I think it was a bad idea to begin with
but at the time I was looking for an expedient solution for getting neighbor
squares 2 squares away.
Overhaul bounds checking in this method so horizontal (west and east) bounds are
checked in addition to vertical (north and south) bounds. For the diagonal
directions in particular, it was easy to generate some bogus neighbor squares
because this method didn't check for wrapping when calculating horizontal
neighbors.
Clippy complained that all the properties of the AllPiecesMoveGenerator struct
had the same suffix. It suggested I remove the _move_generator suffix. So I did.
The move generators should only generate moves that can be made, so calling
make_move() and unmake_move() should never give an error during legal move
generation. Both of these calls assert that the result is not an Err(). Improve
the error messaging so that they log the move, the current board position, and
the error message. Highlight the squares relevant to the move (origin, target,
and capture) when printing the board.
Found another bug in the pawn move generator related to en passant moves. The
generator was emitting e.p. captures even when no pawn was available to capture
on that target square.
The solution was to include the e.p. square in the enemies list, effectively
treating the e.p. target as if it were occupied by an enemy piece, and then remove
it from the capture bitboards before move generation.
Include a couple tests to exercise this functionality.
Move this file over to position/tests. That makes it an integration test, technically.
Update it to comply with the current API conventions. This is a pretty radical
change from when I first wrote these!
In the process of running these tests, I found a bug in my PawnMoveGenerator where
it was generating the origin squares for en passant captures incorrectly. Fix
those bugs and write two new tests to exercise those code paths.
One of the test_board! variants was setting .active_color instead of using the
setter. This is a build failure. Fix it.
Move the assert_move_list! macro to the moves crate. This is a more natural home
for it. Additionally, add assert_move_list_contains! and assert_move_list_does_not_contain!
to generate assertions that a collection of moves (anything that implements
.contains()) has or doesn't have a set of moves. Also remove formatted_move_list!,
which is no longer used.
All that done, make the tests pass!
Make the struct fields private and export getters and various setters for
manipulating the data.
Update all the references to these fields to use the getters and setters instead.
Make the struct attribute private, and export two new methods. A getter, active_color(),
and a setter, set_active_color().
Update all references to the attribute to use the methods.
Instead of inheriting the MakeMove and UnmakeMove traits by being a BoardProvider,
implement bespoke versions of these two methods. This gives Position a chance to
do some of its own work (tracking captures, move records, etc) when making a move.
Pass the move record by reference to the unmake_move() method. Saves a copy.
Export the Result types for MakeMove and UnmakeMove.
Declare an UnmakeMove trait in the moves crate, just like the MakeMove trait from
an earlier commit. Implement this trait for all types that also implement
BoardProvider.
Bring in a whole pile of unit tests from Claude. (Holy shit, using Claude really
saves time on these tests…) Several of these tests failed, and all of those
failures revealed bugs in either MakeMove or UnmakeMove. Huzzah! Include fixes for
those bugs here.
Declare a MakeMove trait and export it from chessfriend_moves. Declare a
BoardProvider trait that both Board and Position implement.
Implement the MakeMove trait for all types that implement BoardProvider, and move
all the move making code to the moves crate.
This change makes it possible to make moves directly on a Board, rather than
requiring a Position. The indirection of declaring and implementing the trait
in the moves crate is required because chessfriend_board is a dependency of
chessfriend_moves. So, it would be a layering violation for Board to implement
make_move() directly. The board crate cannot link the moves crate because that
would introduce a circular dependency.
The moves command writes all possible moves to the terminal.
Move the previous implementation of the moves command, which marked squares that
a piece could move to, to a 'movement' command.
A generator that yields moves for all pieces on the board. This generator combines
the shape-specific move generators developed in prior commits into a single
iterator that yields all moves.
Implement FusedIterator for all generators so AllPiecesMoveGenerator can avoid
doing a bunch of extra work once each iterator has yielded None.
Implement a move generator that emits moves for the king(s) of a particular color.
There will, of course, only ever be one king per side in any valid board, but
this iterator can (in theory) handle multiple kings on the board. This iterator
is almost entirely copypasta of the SliderMoveGenerator. The major difference is
castling.
Castle moves are emitted by a helper CastleIterator type. This struct collects
information about whether the given color can castle on each side of the board
and then emits moves for each side, if indicated.
Do some light refactoring of the castle-related methods on Board to accommodate
this move generator. Remove the dependency on internal state and rename the
"can_castle" method to color_can_castle.
In order to facilitate creating castling moves without relying on Board, remove
the origin and target squares from the encoded castling move. Code that makes
a castling move already looks up castling parameters to move the king and rook to
the right squares, so encoding those squares was redundant. This change
necessitated some updates to position.
Lastly, bring in a handful of unit tests courtesy of Claude. Apparently, it's my
new best coding friend. 🙃
This generator produces moves for slider pieces: bishops, rooks, and queens. All
of these pieces behave identically, though with different sets of rays that
emanate from the origin square. Claude helped me significantly with the
implementation and unit testing. All the unit tests that took advantage of Claude
for implementation are marked as such with an _ai_claude suffix to the test name.
One unique aspect of this move generator that Claude suggested to me was to use
loop { } instead of a recursive call to next() when the internal iterators expire.
I may try to port this to the other move generators in the future.
To support this move generator, implement a Slider enum in core that represents
one of the three slider pieces.
Add Board::bishops(), Board::rooks() and Board::queens() to return BitBoards of
those pieces. These are analogous to the pawns() and knights() methods that return
their corresponding pieces.
Also in the board create, replace the separate sight method implementations with
a macro. These are all the same, but with a different sight method called under
the hood.
Finally, derive Clone and Debug for the bit_scanner types.
ply! implements a small DSL for writing moves in code using a natural-ish
algebraic notation.
assert_move_list! takes a generator and an expected list of moves and asserts
that they're equal. This macro is mostly a copy from one I wrote earlier in the
position crate.
Add another sub-iterator to the PawnMoveGenerator that produces promotion pushes
or capture moves (depending on move_type) when a pawn moves to the back rank.
Also implement en passant moves.
Fix a bug in the Left and Right captures branches where the wrong neighbors used
to calculate origin squares.
Add a whole bunch of tests. Still missing several cases though.
I used Claude to help me figure this out. First time using AI for coding. It was
actually rather helpful!
Calculate BitBoards representing the various kinds of pawn moves when the move
generator is created, and then iterate through them.
En passant still isn't implemented here. This code has not been tested yet either.
Add white castling for both wings. Found some bugs in how king sight is computed
while writing these.
In order for the king to perform the castle, the Movement bitboard needs to return
the two squares the king can castle to. That means anytime movement is calculated
for the king, the (relatively expensive) castling evaluation needs to happen.
Write two new helper static functions to create a Move for castling and promotion
moves. Since structs cannot have any functions with the same name, the two methods
that return properties related to those moves (Move::castle and Move::promotion)
need to be renamed. They're now called Move::castle_wing and Move::promotion_shape.
Implement making double push and promotion moves. Then write several tests to
exercise these. Add convenient static functions to the Move struct to build moves
quickly, without using the Builder.
Add a is_promotable_rank() method to Rank to check that a rank can be used for
promotion moves.
The tests found and fixed a bug in pawn movement where the en passant square was
being discarded when deciding whether an e.p. move can be made.
Implement a new method on Position that evaluates whether the active color can castle
on a given wing of the board. Then, implement making a castling move in the position.
Make a new Wing enum in the core crate to specify kingside or queenside. Replace the
Castle enum from the board crate with this one. This caused a lot of churn...
Along the way fix a bunch of tests.
Note: there's still no way to actually make a castling move in explorer.
Implement thiserror::Error for a bunch of error types, and remove string errors
from the implementation of the command handler in explorer.
Clean up parsing of basic types all over the place.
Update Cargo files to include thiserror and anyhow.
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.
