Go to Definition regressed: in non-package projects, cross-file symbols resolve only when loaded via a literal `source("...")`

[benzipperer]

System details:

Positron and OS details:

Positron Version: 2026.07.1 build 5
Code - OSS Version: 1.118.0
Commit: d3cdd60
Date: 2026-07-08T19:52:09-06:00
Electron: 39.8.8
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-1028-oem

Session details:

R 4.5.3

Describe the issue:

In a non-package R project, Go to Definition (Ctrl+click / F12) no longer navigates to a function defined in another file unless that file is loaded via a literal source("<string>") call.

A dynamic loader like lapply(list.files("R"), source), source(path_var), targets::tar_source(), etc. leaves the callee unresolvable, even though the workspace symbol index still knows where it lives, as "Go to Symbol in Workspace" finds it and opens the file from a static scan of files on disk. Loading the function into the session doesn't help either.

R packages are not affected: a package's R/ files are collated and resolve each other cross-file with no source() call at all. The regression is specific to non-package projects that load R/ dynamically.

Dynamic loaders worked through Positron 2026.06.1 (ARK 0.1.251+242) and broke in 2026.07.0 (ARK 0.1.252+).

It would be excellent to restore this behavior somehow because Ctrl+click/F12 behavior was a very useful tool in Positron (and Rstudio) to locate function definitions.

Steps to reproduce the issue:

The three files are at https://github.com/benzipperer/ctrl_click, or reproduce inline:

static_helper.R

greet_static_helper <- function() {
  paste("Hello world")
}

R/dynamic_helper.R

greet_dynamic_helper <- function() {
  paste("Hello world")
}

main.R

greet_local <- function() {
  paste("Hello world")
}
source("static_helper.R")
lapply(list.files("R", full.names = TRUE), source)

greet_local()          # Ctrl+click -> same-file: JUMPS
greet_static_helper()  # Ctrl+click -> cross-file via literal source(): JUMPS
greet_dynamic_helper() # Ctrl+click -> cross-file via dynamic source(): FAILS

1. Open the folder in Positron (File > Open Folder). Open main.R; wait for the
   R Language Server (ARK) to initialize.
2. Ctrl+click each of the three calls on the last three lines.

Expected or desired behavior:

Ctrl+click	Loaded via	Expected	Actual
greet_local	same file	jump	jumps ✓
greet_static_helper	literal source("static_helper.R")	jump	jumps ✓
greet_dynamic_helper	lapply(list.files("R"), source)	jump to R/dynamic_helper.R	nothing happens ✗

Suggested fixes

I think I understand why y'all moved away from guessing across the workspace but could there be some way to accommodate non-packages?

Could you collate a recognized non-package R/ project like a package? ARK already does this for packages. Extending that to a non-package workspace with a R/ directory would fix many targets-based pipelines and similar lapply(list.files("R"), source) strategies. One potential downside is that this would still miss projects that contain script containing directories common in data analysis like code, etc.

Alternatively, or in addition, could you use a srcref fallback? Loading the function doesn't help today because the live session isn't consulted, but that srcref is exactly what such a fallback could use: when static resolution is empty, consult the session for the symbol and follow its srcref.

Thanks for considering restoring this behavior!

[lionel-]

We're trying to move towards a stronger symbol resolution model that can give us a reliable foundation for more powerful diagnostics (e.g. type checking, unused/unknown symbol, etc). For now only symbol navigation uses this new model, so we can collect feedback. Thanks a lot for reaching out!

Could you collate a recognized non-package R/ project like a package?

That's what we are going to do as a workaround, see #14790. This is only a workaround for files in the R/ folder, so they don't have to be self-contained. We also need a solution for the file that is sourcing the R folder.

tar_source() is easy, we're going to give it a custom Source effect annotation. Unfortunately there is no base R way of sourcing a whole folder. The idiom is to loop across list.files(), which we might need to support in some way with a ListFiles/ListDir effect (that other functions e.g. from the {fs} package could implement too).

We could also support the following annotation as an escape hatch (but only as a last resort, our goal is to avoid users having to write annotations):

declare(Source("my_folder/"))

(Regarding srcrefs, this won't help here. The goal is for LSP features to be immediately available without requiring sourcing the files. Also the final dynamic state after sourcing might not represent the state of the code in the start or middle of the file, or might not represent what happens in other files sourced earlier, etc. Static analysis is strictly more powerful, if we can get the right information about how files are sourced.)

[lionel-]

Let's track this over at #14790