Bumps the cargo-dependencies group with 2 updates: [proc-macro2](https://github.com/dtolnay/proc-macro2) and [serde](https://github.com/serde-rs/serde).


Updates `proc-macro2` from 1.0.83 to 1.0.84
- [Release notes](https://github.com/dtolnay/proc-macro2/releases)
- [Commits](https://github.com/dtolnay/proc-macro2/compare/1.0.83...1.0.84)

Updates `serde` from 1.0.202 to 1.0.203
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](https://github.com/serde-rs/serde/compare/v1.0.202...v1.0.203)

---
updated-dependencies:
- dependency-name: proc-macro2
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: serde
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

I feel like recommending people install Poetry via a package manager was
a mistake. Poetry only supports its latest version, and while newer
versions are sort-of backward-compatible, they print warnings in
different situations and have different bugs. Installing `pipx` via a
package manager, OTOH, works fine, and its older versions work fine.

Using Poetry 1.8+ allows us to use Poetry's new "non-package" mode,
which would no longer print warnings if the user does `poetry install`
instead of `poetry install --no-root`. It's likely that in newer
versions of Poetry, it will become an error.

Since we no longer depend on legacy trees being preserved when we
build new trees or merge trees, we can consider the root tree a
non-legacy tree.

Before this patch, `MergedTreeBuilder::write_tree()` would create a
new legacy tree if the base tree was a legacy tree. This patch makes
it always write multiple root trees instead (if there are conflicts).

We still support reading legacy conflicts if the
`format.tree-level-conflicts` config is set.

It's been about six months since we started using tree-level conflicts
by default. I can't imagine we would switch back. So let's continue
the migration by always using tree-level conflicts when merging trees,
even if all inputs were legacy trees.

This is a small refactoring to return a bit less information from the
block where we merge trees.

In chromium/src.git, this gives an approximate ~0.83s speedup for
commands if the Git index is empty, and a ~0.14s slowdown if the Git
index is non-empty.

As most users using jj will likely be using jj to write to a colocated
repo - and therefore avoid modifying the Git index - this should be a
general speedup for most colocated checkouts.

The original expand_node() body is migrated as follows:
- Identifier -> fold_identifier()
- FunctionCall -> fold_function_call()

expand_defn() now manages states stack by itself, which simplifies lifetime
parameters.

This could be a closure argument passed to expand_aliases(), but it's nice
that the parsing function is constrained by the aliases map type.

The templater implementation of FoldableExpression is a stripped-down version
of expand_node(). It's visitor-like because I'm going to write generic alias
substitution rules over abstract expression types (template, revset, fileset.)

Naming comes from rustc.
https://rust-unofficial.github.io/patterns/patterns/creational/fold.html

This is basically the same as the previous patch, but for error types. Some
of these functions could be encoded as "E: From<AliasExpandError<'i>>", but
alias substitution logic is recursive, so it would have to convert E back and
force.

This isn't fancy, but we'll need some generic way to return either original
or substituted expression node. I think this is the simplest abstraction.

Without this, the `time` crate fails to compile on today's
nightly.

Unfortunately, a full `cargo update` seems to break Watchman
on Windows:

https://github.com/martinvonz/jj/actions/runs/9233007115/job/25404996847?pr=3755

I think this makes it more readable. It seems to be how most people
write TOML.

Perhaps, the original intent was to abandon non-empty working-copy commit
assuming it was rewritten by git (therefore it should be superseded by the
current working-copy content.) However, there are other reasons that could
make the HEAD out of sync (including concurrent jj operations), and abandoning
non-empty commit can be a disaster. This patch turns it to safer side, and let
user abandon non-empty commit manually.

Fixes #3747

Bumps the cargo-dependencies group with 1 update: [syn](https://github.com/dtolnay/syn).


Updates `syn` from 2.0.65 to 2.0.66
- [Release notes](https://github.com/dtolnay/syn/releases)
- [Commits](https://github.com/dtolnay/syn/compare/2.0.65...2.0.66)

---
updated-dependencies:
- dependency-name: syn
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

Appears that the new version is stricter about CamelCase identifiers?

https://github.com/martinvonz/jj/actions/runs/9217071832/job/25358450632

gix 0.63 is now available.

#3537

I'm going to extract generic alias substitution functions, and these AST types
will be accessed there. Revset parsing will also be migrated to the generic
functions.

This will help extract common FunctionCallNode<'i, T> type. We don't need
freedom of arbitrary error type choices, but implementing From<_> is the
easiest option I can think of. Another option is to constrain error type by
the expression type T through "T::ParseError: ArgumentsParseError" or
something, but it seemed a bit weird that we have to use trait just for that.

As of config 0.13.4, the path Expression type is private, and there's no escape
syntax. This patch adds a fallback to nested HashMap<String, Value> lookup.

https://github.com/mehcode/config-rs/blob/v0.13.4/src/path/mod.rs#L10
https://github.com/mehcode/config-rs/blob/v0.13.4/src/path/parser.rs

Fixes #1723

"config list NAME" argument is now parsed as TOML key, but it's still broken
since config.get() expects a query expression in different syntax.

The other config commands will be migrated later.

Since RepoPath is now a slice type, it can be constructed without cloning the
backing buffer. Let's simply use it instead of the iterator type.

These functions (in `Tree` and `MergedTree`) are safe to use. We have
a duplicate of these functions at Google, which would be nice to
avoid.

I don't think there's any harm in this function being public. We have
a duplicate of it at Google.

Turns out we use some of the functions in `commands/config.rs` at
Google. (We use them for writing name and email if the user hasn't set
them.)

I'm about to make `[Merged]Tree::path_value()` return a `Result`. This
will help even more then.

For the same reason as the templater changes. These FunctionCallNode types will
be extracted as utility type.

This will help extract interface of the error constructor without depending on
T: ExpressionKind type.

I'm thinking of moving them to dsl_util, but we'll probably want to avoid
importing dsl_util at call sites.

I use ValueKind::Ty(ref v) here because (*v).into() looked rather noisy.

Fixes #3374

There are no external callers, so let's make them private.

I add them as aliases, since a user may instead choose to define `immutable_heads()`, for example, as `heads(immutable())`, and the define `immutable()` instead.

This means that <https://martinvonz.github.io/jj/latest/index.html> will
not longer redirect to
<https://martinvonz.github.io/jj/v0.18.0/index.html> (or similar) after
the next release, as requested by @jyn514 on Discord. Instead, it will
be a copy.

Originally, the plan was to use mike's symlink functionality and make
`latest` a symlink. See a comment inline for how that didn't work; we
could do that after changing how GitHub Pages are built.

Before the next `jj` release, and after this PR is merged, you can play
with this by going to <https://martinvonz.github.io/jj/main/> which is
an alias for <https://martinvonz.github.io/jj/prerelease/>.

Because of previous commits in this PR, the latest version will be
marked in the version selector as "latest", so hopefully this won't
confuse users.

Due to the parent commit, the "latest" URL will be considered canonical.

Currently, https://www.google.com/search?q=jj+revsets has problematic
results, one of the top links for me is
https://martinvonz.github.io/jj/v0.14.0/github/ (we are currently on
v0.17.1).

I hope this will help them all point to `latest` instead.

See https://github.com/martinvonz/jj/pull/3723 for a screenshot.

This will make it clearer to the users that the "latest" and "v0.??.?"
are the same even if the former does not redirect to the latter (but has
identical contents).

MkDocs material lists the *first* alias for each version, so I also
added a "nightly" alias for "prerelease". Otherwise, users would see the
"main" alias, and might get confused whether they should use "latest" or
"main" docs if they don't realize it's named after the "main" branch.

(Upon testing, it still shows "main" for now, but it should be possible
to fix this after this PR is merged by reordering the aliases directly
in `versions.json` on the gh-pages branch)

The new version supports showing labels in version selector.

This revset correctly implements "reachability" from a set of source commits following both parent and child edges as far as they can go within a domain set. This type of 'bfs' query is currently impossible to express with existing revset functions.

Fixes #3579 and adds a testcase for an executable conflict treevalue.

Signed-off-by: dependabot[bot] <support@github.com>

Fixes #1322. There may be more places where keys need escaping, I'm not
completely sure.

This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a
label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3
ends".

I didn't initially put any label at the ending delimeter since the
starting delimeter is already marked with "Conflict 1 of 3". However,
I'm now realizing that when I resolve conflicts, I usually go from top
to bottom. The first thing I do is delete the starting conflict
delimeter. It is when I get to the *end* of the conflict that I wonder
whether there are any more conflicts left in the file.

Bumps the github-dependencies group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).


Updates `github/codeql-action` from 2.13.4 to 3.25.6
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/github/codeql-action/compare/cdcdbb579706841c47f7063dda365e292e5cad7a...9fdb3e49720b44c48891d036bb502feb25684276)

---
updated-dependencies:
- dependency-name: github/codeql-action
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>