BUG: Root directories in windows are not being handled correctly resulting in stack overflow

[Universal-Invariant]

Did you check docs and existing issues?

• I have read all the docs.
• I have searched the existing issues.
• I have searched the existing discussions.

Neovim Version (nvim -v)

NVIM v0.12.0-dev-1387+gf67306cc67

Operating System / Version

Win 11 24H2

Describe the Bug

I cannot use Neotree in any root directory. Works fine in any non-root directory.
This also happens with treesitter find_files but not in oil.

Screenshots, Traceback

 Error 8:54:54 PM msg_show.lua_error vim.schedule callback: stack overflow
stack traceback:
[C]: in function 'gsub'
...neo-tree.nvim/lua/neo-tree/sources/common/file-items.lua:72: in function 'deep_sort'
...neo-tree.nvim/lua/neo-tree/sources/common/file-items.lua:90: in function 'deep_sort'
...neo-tree.nvim/lua/neo-tree/sources/common/file-items.lua:90: in function 'deep_sort'

Inspecting

contains_reveal_target = false,
id = "Z:",
is_reveal_target = false,
loaded = false,
name = "Z:",
parent_path = "Z:\\",
path = "Z:",
type = "directory"

In treesitter I get the error that it cannot find fd in Z:\Z:.

I believe the issue likely is because it's comparing the parent_path of Z:\ with Z: because there was a "fix" which says that windows paths must be 3 chars. But then root paths are not properly compared because of this. This likely is in plenary.

folke/snacks.nvim#961
nvim-lua/plenary.nvim#564
nvim-lua/plenary.nvim#489

Steps to Reproduce

Install lazyvim or astro, open nvim up in root directory

Expected Behavior

Obviously for it to work.

Your Configuration

-- template from https://lazy.folke.io/developers#reprolua, feel free to replace if you have your own minimal init.lua
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    {
      "nvim-neo-tree/neo-tree.nvim",
      branch = "v3.x", -- or "main"
      dependencies = {
        "nvim-lua/plenary.nvim",
        "nvim-tree/nvim-web-devicons", -- not strictly required, but recommended
        "MunifTanjim/nui.nvim",
        -- { "3rd/image.nvim", opts = {} }, -- Optional image support
      },
      lazy = false,
      ---@module "neo-tree"
      ---@type neotree.Config?
      opts = {
        -- fill any relevant options here
      },
    }
  },
})
vim.g.mapleader = " "
vim.keymap.set("n", "<leader>e", "<Cmd>Neotree<CR>")
-- do anything else you need to do to reproduce the issue

[Universal-Invariant]

This is where I think the regression was introduced: #986
or here: nvim-lua/plenary.nvim@0b7a85b

If windows paths must have a separator then the issue is that it is being removed. Either way it seems that a better comparison should be had. I think treesitter likely has a similar bug.

For example, if I forcibly remove all trailing ''s then I do not get the stack overflow

M.split_path = function(path)
  if not path then
    return nil, nil
  end
  if path == M.path_separator then
    return nil, M.path_separator
  end
  local parts = vim.split(path, M.path_separator, { plain = true })
  local name = table.remove(parts)
  ---@type string?
  local parentPath = table.concat(parts, M.path_separator)
  local prefix = M.abspath_prefix(path)
  if #parentPath == 0 and prefix then
    parentPath = prefix
  end  
  parentPath = trim(parentPath, "\\")
  path = trim(path, "\\") 
  return parentPath, name
end

But I also do not get any subdirectories listed(It only shows Z:\ in my case as if it contained no subdirectories)

If I force slashes then I get one less recursion but I still get the infinite recursion. That is, when I print out the variables, I end up getting duplicates because there are slight variations in the slashes.

In any case, there definitely is a bug somewhere in the code dealing with how paths are compared relating to the trailing backslash. I don't know enough about the code to know where the problem is but it clearly has to do with where it recurses over the directories and mishandles root dirs. It needs a more sophisticated check.

[pynappo]

probably a regression w/ split_path behavior, will fix asap