Open juliasilge opened 7 months ago
The clangd extension (https://github.com/clangd/vscode-clangd) is open source but requires a bit more configuration: a compile_commands.json
file that contains compiler flags for each file. Once set up correctly though, it's a very good analyzer.
It's been on our longer-term todo list to look into integration with pkgload / pkgbuild to construct the compilation database. I'm using https://github.com/rizsotto/Bear which works well. Windows support might be tricky: https://github.com/rizsotto/Bear/issues/431
Should we aim for RC for this issue?
Would you vote for RC @lionel-? I think we'll discuss in the next triage meeting as well.
Besides R packages using C++ there are also standalone C++ files that can be sourced using Rcpp::sourceCpp
or cpp11::cpp_source()
. In the RStudio IDE the "source" button uses these functions directly, which allows for convenient workflows.
@juliasilge I think it's a nice-to-have for RC but not a blocker. Do we add such aspirational items to milestones and remove them later on if time is short?
Could Positron generate compile_commands.json
by hand for the user? Either by inspecting the output of R CMD SHLIB --dry-run
, or something similar with running make -n
?
It'd be nice if this worked at least for the most common configurations, for packages containing some C / C++ files with perhaps some minimal versions of Makevars supported.
https://github.com/r-lib/pkgload/pull/285 brings us much closer by making it possible to update a compile_commands.json
file on each load_all()
. This makes the package compatible with the clangd LSP server.
A manual intervention is required to set it up, currently the user needs to call pkgload:::use_compilation_db()
(this will be exported from usethis in the future). We'll need to think about whether and how to advertise this on the frontend side. We could detect C/C++ code and a missing Config/build/compilation-database
field in DESCRIPTION
and prompt the user about whether they want to maintain a compilation database with devtools? This would be annoying to users of non-devtools workflows though.
A fair amount of R packages involve C++ code, such as those using cpp11 or Rcpp. Let's consider how to support workflows where folks use C++. R package developers like to use VS Code for this, but the main extension(s) are proprietary and not on OpenVSX.