Languages

Bugsaur is language-agnostic: it speaks DAP, and the language-specific knowledge lives in the adapter. What differs between languages is which adapter to use, what program means, and what tends to go wrong.

What is supported

Language	Adapter	Project detected by	program is
Rust	codelldb	Cargo.toml	a compiled binary
C / C++	codelldb	not detected — configure by hand	a compiled binary
Go	dlv	go.mod	a package directory
Python	debugpy	pyproject.toml, setup.py, requirements.txt	a script
PHP	php (built in)	composer.json	the project directory

C and C++ have no auto-detection

bugsaur init recognises four languages, and C/C++ is not among them: there is no single marker file that identifies a C project. The adapter — the same codelldb used for Rust — works fine; you write the profile by hand. See C / C++.

What bugsaur init generates

Detection walks up from where you ran it, and the nearest project wins over any enclosing one. Then it writes one profile per thing worth debugging:

Language	One profile per
Rust	binary: every [[bin]], or a package with src/main.rs. Libraries get none
Go	directory with package main: the module root and direct cmd/* subdirectories
Python	entry point: main.py, app.py, manage.py, __main__.py in the root, and src/<pkg>/__main__.py
PHP	the project

A project with no debuggable entry point produces no profiles, and the launch stops with an error rather than writing a config with an invented program in it.

What is the same everywhere

• Relative paths resolve from the project root — the nearest directory up the tree containing .bugsaur/.
• The working directory defaults to the project root, not to the program's directory. See Configuration → Working directory.
• ${root} expands to the absolute project root in env, args, adapter_command and launch_arguments.
• Breakpoints live in .bugsaur/breakpoints.json and are shared with the editor.

Coverage at a glance

✅ works by default · ⚠️ one explicit line in the profile · ❌ not covered

Scenario	Go	Rust	Python	PHP
.env in the root, the app reads it itself	✅	✅	✅	—
.env the app does not read itself	⚠️ env_file	⚠️ env_file	⚠️ env_file	—
Relative paths to configs/, migrations/	✅	✅	✅	—
Several debuggable parts	✅ cmd/*	✅ per binary	✅ per entry point	—
Command-line arguments	✅ args	✅ args	✅ args	—
Entry point in an unusual place	⚠️	✅	⚠️	—
Monorepo, shared .env above the root	⚠️ env_file = "../..."	⚠️	⚠️	—
Debugging tests with testdata/	⚠️ cwd	⚠️ cwd	⚠️ cwd	—
Launch without building first	✅	❌ build it yourself	✅	—
go.work / several modules	❌	—	—	—
Working directory and environment	✅	✅	✅	❌ by design

PHP is dashed rather than ticked in most rows because its adapter launches nothing — it listens, and the PHP process is started by somebody else. The PHP page explains what that changes.