Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.
Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
This is necessary in cases where filetype detection acts recursively.
For example, when matching files that end with .bak, the "root" of
the filename is matched again against the same buffer (e.g. a buffer
named "foo.c.bak" will be matched again with the filename "foo.c", using
the same underlying buffer).
Omitting 'pattern' in nvim_exec_autocmds should be equivalent to
omitting the 'fname' argument in :doautoall, which is equivalent to
using an empty string as the pattern. Fixes regression introduced
in #19091.
Problem: Crash when going through spell suggestions.
Solution: Limit the text length for finding suggestions to the original
length. Do not update buffers when exiting. (closesvim/vim#8965)
e275ba4fc9
This enables vim.filetype.match to match based on a buffer (most
accurate) or simply a filename or file contents, which are less accurate
but may still be useful for some scenarios.
When matching based on a buffer, the buffer's name and contents are both
used to do full filetype matching. When using a filename, if the file
exists the file is loaded into a buffer and full filetype detection is
performed. If the file does not exist then filetype matching is only
performed against the filename itself. Content-based matching does the
equivalent of scripts.vim, and matches solely based on file contents
without any information from the name of the file itself (e.g. for
shebangs).
BREAKING CHANGE: use `vim.filetype.match({buf = bufnr})` instead
of `vim.filetype.match(name, bufnr)`
With 4c7462fdb3, when `libintl` is turned off via
`-DENABLE_LIBINTL=OFF`, Neovim does not compile in Debug mode with the following
error message:
```
...
[201/331] Building C object src/nvim/CMakeFiles/nvim.dir/eval.c.o
FAILED: src/nvim/CMakeFiles/nvim.dir/eval.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DEXITFREE -DINCLUDE_GENERATED_DECLARATIONS -DMIN_LOG_LEVEL=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -Dnvim_EXPORTS -I/Users/hat/Projects/neovim/build/config -I/Users/hat/Projects/neovim/src -I/Users/hat/Projects/neovim/build/src/nvim/auto -I/Users/hat/Projects/neovim/build/include -I/Users/hat/Projects/neovim/.deps/usr/include/luajit-2.1 -isystem /Users/hat/Projects/neovim/.deps/usr/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -g -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -Wno-conversion -MD -MT src/nvim/CMakeFiles/nvim.dir/eval.c.o -MF src/nvim/CMakeFiles/nvim.dir/eval.c.o.d -o src/nvim/CMakeFiles/nvim.dir/eval.c.o -c /Users/hat/Projects/neovim/src/nvim/eval.c
/Users/hat/Projects/neovim/src/nvim/eval.c:473:3: error: implicit declaration of function 'free_locales' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
free_locales();
^
/Users/hat/Projects/neovim/src/nvim/eval.c:473:3: note: did you mean 'free_titles'?
/Users/hat/Projects/neovim/build/include/buffer.h.generated.h:58:16: note: 'free_titles' declared here
DLLEXPORT void free_titles(void);
^
1 error generated.
[212/331] Building C object src/nvim/CMakeFiles/nvim.dir/eval/funcs.c.o
ninja: build stopped: subcommand failed.
make: *** [nvim] Error 1
```
The previous commit, b1b5802009, to 4c7462f does
not have this issue. As you can see in the following, the issue occurs only in
Debug mode with `libintl` turned off:
```bash
# No issue
git checkout b1b5802
# The following Debug build works
make distclean; make SDKROOT=$(xcrun --sdk macosx --show-sdk-path) CMAKE_EXTRA_FLAGS="-DENABLE_LIBINTL=OFF"
# The following Release build works
make distclean; make CMAKE_BUILD_TYPE=Release SDKROOT=$(xcrun --sdk macosx --show-sdk-path) CMAKE_EXTRA_FLAGS="-DENABLE_LIBINTL=OFF"
# Compile error when in Debug and libintl turned off
git checkout 4c7462f
# The following Debug build does not work
make distclean; make SDKROOT=$(xcrun --sdk macosx --show-sdk-path) CMAKE_EXTRA_FLAGS="-DENABLE_LIBINTL=OFF"
# The following Debug build works
make distclean; make SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
# The following Release build works
make distclean; make CMAKE_BUILD_TYPE=Release SDKROOT=$(xcrun --sdk macosx --show-sdk-path) CMAKE_EXTRA_FLAGS="-DENABLE_LIBINTL=OFF"
```
I noticed this because I turn `libintl` off when compiling `libnvim` for VimR.
Fix#19093
Problem:
Nvim fails to create tempfile "…/nvim6UJx04/7" when 'shell' is set to
pwsh (PowerShell Core). This breaks filtered shell commands ":{range}!".
With shell set to cmd, it works.
Solution:
PowerShell doesn't use "<" for stdin redirection. Instead, use
"-RedirectStandardInput".
Closes#15913
Problem: #19029 added a new fallback that sets
`$MACOSX_DEPLOYMENT_TARGET` to the local macOS version via `sw_vers`.
However, the output included a newline, which broke the generated Ninja
build script.
Solution: use `OUTPUT_STRIP_TRAILING_WHITESPACE` for `execute_process`.
Problem: 'completefunc'/'omnifunc' error does not end completion.
Solution: Check if there was an error or exception. (closesvim/vim#10486,
closesvim/vim#4218)
9bcb9ca9c7
This re-introduces the fix that the filetype.lua refactor inadvertently reverted.
The fix ensures that in the case when end_lnum is omitted, a string is always returned.
After some tweaks to our dep builds, we can now build a universal binary
for macOS by using `CMAKE_OSX_ARCHITECTURES`. So, let's do that. This
requires a number of additional changes:
1. We need to build on macOS 11, since earlier versions do not support
building universal (M1 + Intel) binaries.
2. We need to provision a universal `libintl`. The linker will look for
an ARM64 version of this library when linking the `nvim` binary.
While we're here:
1. Link statically to `libintl`. This allows to to avoid having to do
any install name rewriting or codesigning to package Neovim.
2. Bump the `MACOSX_DEPLOYMENT_TARGET` to `11`. We're already using a
`libintl` built by Homebrew (through the pre-installed version of
`gettext`), and that is built for macOS 11.
In order to ensure we link to `libintl.a` instead of `libintl.dylib`, we
have to make sure that CMake can't find the latter. This ideally should
be a matter of doing `brew unlink gettext`. However, CMake is too adept
at finding things that Homebrew has installed (even when not linked), so
we have to do a bit more than that. This appears in the additional step
ensuring static linkage to `libintl`.
We end up breaking some Homebrew-installed software in the process, and
some of these software is called during our build (e.g. curl, git,
wget). To avoid any adverse effects, let's just uninstall them.
CMake can handle building universal binaries on macOS using the
`CMAKE_OSX_ARCHITECTURES` variable. Let's pass this variable to the
relevant dep builds. We use the `LIST_SEPARATOR` argument to prevent the
shell from interpreting the `;` that CMake uses as a list separator.
For dependencies that don't build using CMake, we only need to make sure
that the compiler is invoked with the correct `-arch` flags. The
compiler does the rest.
The only exception to this is the LuaJIT build, which we handle
separately as a special case.
To build universal binaries on macOS, one typically only needs to pass
multiple `-arch` flags to `clang`.
Unfortunately, this strategy causes LuaJIT builds to fail. To work
around this, we build LuaJIT for each requested architecture
individually first and then use `lipo` to package each architecture
slice into a universal binary.
To be able to do this on an Intel macOS host or an M1 macOS host without
a Rosetta installation, we need some special flags in order to tell
LuaJIT that it is cross-compiling for a different target. See [1] for
details.
[1] https://luajit.org/install.html#cross
