Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of this change).
Splitting it on word boundaries rather than only spaces allows for better
detection. The issue labeler previously didn't catch titles such as
`treesitter: noisy "Invalid node type" error`.
Co-authored-by: casswedson <casswedson@users.noreply.github.com>
Run the release workflow on macos-14 to use faster M1 runners.
Lock the deployment target to the oldest supported version (11.0,
due to libuv support) instead of relying on the host OS version.
Problem: No test coverage on ARM.
Solution: Add `macos-14` tests, which now run on M1. Skip unit tests as these don't work on M1, see #26145. Also test universal build on M1.
Note: `macos-14` will be `macos-latest` in Q2 2024, so we'll want to switch these to keep Intel and unittest coverage on macos (while GH still offers Intel runners).
Explicitly set the build type for both deps and Nvim. They are already
explicitly set on Windows to RelWithDebInfo. Now also explicitly set
them to Debug on POSIX.
- Consistently use the variable CMAKE_BUILD_TYPE to select build type.
- Remove broken `doc_html` target.
- Remove swap files created by oldtest when cleaning.
- Only rerun `lintdoc` if any documentation files has changed.
Summary: Separate the lint job (`make lintdoc`) to validate runtime/doc,
it is no longer as a part of functionaltest (help_spec).
Build (cmake) and CI:
- `make lintdoc`: validate vimdoc files and test-generate HTML docs.
CI will run this as a part of the "docs" workflow.
- `scripts/lintdoc.lua` is added as an entry point (executable script)
for validating vimdoc files.
scripts/gen_help_html.lua:
- Move the tests for validating docs and generating HTMLs from
`help_spec.lua` to `gen_help_html`. Added:
- `gen_help_html.run_validate()`.
- `gen_help_html.test_gen()`.
- Do not hard-code `help_dir` to `build/runtime/doc`, but resolve from
`$VIMRUNTIME`. Therefore, the `make lintdoc` job will check doc files
on `./runtime/doc`, not on `./build/runtime/doc`.
- Add type annotations for gen_help_html.
Problem: Commits backport-merged to release branches are cherry-picked
from the original commits in the PR from a fork repository, NOT the
actual commit that are merged to neovim/neovim (HEAD). Therefore the
commit reference in the commit message `cherry picked from commit ...`
usually refers to a commit that does NOT exist in the repository,
given that our preferred way of merging PR (rebasing, squashing, etc.)
would rewrite commits.
Solution: Turn on new feature 'detect_merge_method' of backport-action
workflow.
All releases that aren't directly maintained by us should live in the
`neovim/neovim-releases` repository to make it clear that neovim isn't
directly responsible for it and to correctly manage expectations that
it's provided on a best-effort case.
Closes https://github.com/neovim/neovim/issues/26717.
The benefits are primarily being able to use FetchContent, which allows
for a more flexible dependency handling. Other various quality-of-life
features such as `-B` and `-S` flags are also included.
This also removes broken `--version` generation as it does not work for
version 3.10 and 3.11 due to the `JOIN` generator expression.
Reference: https://github.com/neovim/neovim/issues/24004
Notable changes:
- Downloads are significantly faster, upwards of 90% improvement in worst case
scenarios.
- Artifacts can be downloaded from other workflow runs and repositories when
supplied with a PAT.
Python3 provider tests suddenly became extremely flaky on macos for
unknown reasons. For some reason, installing python with the
setup-python action over using the default python fixes the flakiness.
Use this workaround for the time being to unblock CI while we figure out
the root cause.
- silence false warnings on MSVC
- merge `clang-tidy` cmake target into `lintc` and remove the
corresponding make target
- use cmake's built-in endianness detection
In cases where the generated files depend on changes to Nvim itself,
generating the files with an older version of Nvim will fail because
those changes are not present in the older version.
For example, if a new option is added then the generator script should
be run with the version of Nvim that contains the new option, or else
the generation will fail.
Co-authored-by: dundargoc <gocdundar@gmail.com>
These are meant for expensive or situational tests that may not be
suitable to run each time, but can occasionally be useful.
Currently only add testing for s390x. The job is enabled by adding the
ci-s390x label in github.
This will run the three test suites (unit, functional and old) in
parallel, meaning that neovim is built for each test and run separately.
This has a slight increase in total CI usage, but it allows rerunning
only the specific test suite that failed for flaky tests, which will
save some time.
Ideally we'd remove any drawbacks by building neovim once and reusing it
for each test suite, but that is not currently possible due to poor
upload/download speeds of the upload-artifact and download-artifact
actions. This has been addressed in
https://github.com/actions/toolkit/pull/1488, but will only be made
available in upload-artifact@v4 and download-artifact@v4.
This adds the checks in https://neovim.io/doc/reports/clang/ when using
clang-tidy. The strategy is to enable all clang-analyzer checks, and
disable only the checks for the warnings that exist currently. This
allows us to eliminate each warning type without blocking ongoing work,
but also without adding bugs for already eliminated warnings.
The plan is to eventually eliminate https://neovim.io/doc/reports/clang/
by completely integrating it into the clang-tidy check.
Also add make and cmake targets `clang-analyzer` to run this check.
This reverts commit e71c7898ca.
Triggering jobs on users own fork turned out to be not that useful, and
only necessary in rare moments. It's easier to adjust the CI scripts if
the users wants CI results before creating a pull request. It also
reduces the complexity of the CI code.
This will fix the failing release job.
Ubuntu 18.04 is incompatible with checkout action version 4, which
requires glibc 2.28+. This will bump the minimum glibc version required
to use the release versions to 2.31. People requring the older releases
can find them at https://github.com/neovim/neovim-releases.
