Newly merged toml support is broken

[rymdbar]

Information

VIM version VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jul 19 2025 02:13:20) Included patches: 1-1566

Operating System: Linux 6.12.41-0-lts #1-Alpine SMP PREEMPT_DYNAMIC 2025-08-07 06:15:54

What went wrong

It seems pull request #5022 was merged a bit too speedily without sufficient quality assurance. I was meaning to comment on it, but instead focused on the prior PR #4975 also by @mathstuf.

Reproducing the bug

1. Create a new project directory. cd $( mktemp -d /tmp/ale_XXXXXX )
2. Initialize a Rust project in it. cargo init
3. Edit Cargo.toml. gvim Cargo.toml
4. Change the edition to an invalid value. :.,$s/\(edition = "202\)./\13/

Here we should expect an error message, but none occurs. Instead there are errors in :ALEInfo about the language server not starting.

:ALEInfo

commit: d6f1a47

Applying the following patch ought to solve this specific issue:

diff --git a/ale_linters/toml/tombi.vim b/ale_linters/toml/tombi.vim
index 59c8da40..a43f0455 100644
--- a/ale_linters/toml/tombi.vim
+++ b/ale_linters/toml/tombi.vim
@@ -27,7 +27,7 @@ function! ale_linters#toml#tombi#GetProjectRoot(buffer) abort
     endif
 
     " Try to find nearest `git` directory
-    let l:gitdir = ale#path#FindNearestFile(a:buffer, '.git')
+    let l:gitdir = ale#path#FindNearestDirectory(a:buffer, '.git')
 
     if !empty(l:gitdir)
         return fnamemodify(l:gitdir . '/', ':p:h:h')

Since no one did a full review of #5022 there might be other issues. Thus this issue is primary a question to @mathstuf whether you could please open a new PR based on the above patch?

[mathstuf]

Will do.

[mathstuf]

Hmm. That is going to fail for worktrees (where .git is a file). Perhaps this warrants a ale#path#FindNearestGitRoot(a:buffer) call which calls out to git rev-parse --show-toplevel?

[rymdbar]

Hmm. That is going to fail for worktrees (where .git is a file).

Oh.

% cat .git
gitdir: /tmp/ale_PiMKcB/.git/worktrees/wt

Indeed it is! I'm amazed this hasn't bitten me in the past. Or maybe it has, and I just haven't realized navigating out of the worktree‽

Perhaps this warrants a ale#path#FindNearestGitRoot(a:buffer) call which calls out to git rev-parse --show-toplevel?

Seems very reasonable to me! Maybe that's its own PR given how many lsp:s (and other tools?) which use this pattern.

I was going to suggest checking for Cargo.toml too. Possibly attempting to activate the Rust specific extensions if that was found, but didn't really dive in to how they work yet.

[mathstuf]

Yes, I think migrating other tools over to it makes sense.

I considered finding the root for Cargo.toml, but…that is always going to be itself except when in a workspace…and we don't know where to stop for that without parsing.

[rymdbar]

I considered finding the root for Cargo.toml, but…that is always going to be itself except when in a workspace…and we don't know where to stop for that without parsing.

The Cargo Book has a chapter on Workspaces and other one on The Manifest Format. According to tombi docs, regarding the tombi-extension-cargo:

The extension is context-aware: when a dependency uses workspace = true, it looks up features from the workspace definition.

I can't get it to work though. Creating a fresh directory with an empty .git file, this workspace Cargo.toml

[workspace]
members = ["foo", "serde"]
edidion = "2023"

[workspace.package]
version = "1.2.3"
authors = ["Nice Folks"]
description = "A short description of my package"
documentation = "https://example.com/bar"

…this serde/Cargo.toml …

[package]
name = "serde"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true

[features]
notreally = []

…and finally foo/Cargo.toml

[package]
name = "foo"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true

[dependencies]
serde = { workspace = true, features = [""] }

The initialize call contains the workspace directory for both rootUri and rootPath:

{
    "method": "initialize",
    "jsonrpc": "2.0",
    "id": 2,
    "params": {
        "initializationOptions": {},
        "rootUri": "file:///tmp/ale_HILloO",
        "capabilities": { … },
        "rootPath": "/tmp/ale_HILloO",
        "processId": 15328
    }
}

The suggested completions for features are serde proper ones, rather than "notreally".

Is this working for someone else?

On an unrelated issue, I just realized tombi sends network requests unless configured to work in offline-mode. Given how unexpected that is, I would argue for it being made disabled by default in ALE. At the very least the ale-toml.txt should mention it.

[mathstuf]

On an unrelated issue, I just realized tombi sends network requests unless configured to work in offline-mode. Given how unexpected that is, I would argue for it being made disabled by default in ALE. At the very least the ale-toml.txt should mention it.

See #5032.

I can't get it to work though. Creating a fresh directory with an empty .git file, this workspace Cargo.toml

Sounds like a tombi bug to me, but I really don't know. I don't really use other LSP-aware editors to test its behavior separately from ALE. There's really not much going on here on the ALE side that is tombi-specific…