Christian Clason

Related parser issue: https://github.com/camdencheek/tree-sitter-dockerfile/pr/52 See also https://github.com/nvim-treesitter/nvim-treesitter/pull/6574

Current master is failing the Neovim tests on Windows and (intermittently) macOS; I'll bisect today. The offending commit must be between https://github.com/libuv/libuv/commit/4e310d0f90af29e699e2dedad5fa0dcee181a7cc (good) and https://github.com/libuv/libuv/commit/9b3b61f606cbc4df1680a1aa08959c91023d99eb (bad).

Bisected to https://github.com/libuv/libuv/commit/727ee7237ede117c539a64258bf82a1b36b9991e (test hang on Windows).

(It's not just Node; Neovim is affected by the `fs-watch` issue as well; for some reason it was only exposed by the changes in the UBSAN commit, though.)

Easiest if I link the failing tests: * [macOS fswatch failures](https://github.com/neovim/neovim/actions/runs/10431268093/job/28890739255) (type of change is detected incorrectly), bisected to https://github.com/libuv/libuv/commit/9b3b61f606cbc4df1680a1aa08959c91023d99eb * [Windows test hang](https://github.com/neovim/neovim/actions/runs/10431581693/job/28891392804) when waiting for stdin, bisected to...

Possibly, but the effect of the commit is reproducible. _Somehow_ it surfaced the issue for that specific change (file deletion, so the "length == 0" change in that commit conceivably...

You mean revert on top of the UBSAN fixes? (Because the test failures only appeared with the latter.) Since I cannot reproduce the failures locally on my machine, that would...

(And to be clear, the Windows hang is much more worrying and a blocker for us.)

Not really, sorry, since the hang is on Windows only (and hanging means no test failure to investigate).

This was added in https://github.com/vim/vim/commit/a907c91992167e41da41008d4370e434e324cbf2 by the maintainer, @tpope. Upstream is https://github.com/tpope/vim-haml.