[giuseppe-esposito-87]

🤖 This was written by an AI agent on behalf of @giuseppe-esposito-87 (claude-code/claude-opus-5-5).

Adds DR2: in a Drupal site, service IDs work the way they do in a Symfony project.

• Completion, go to definition and references for the service IDs and container parameters that core, contributed and custom modules declare in *.services.yml, wherever a services file, $container->get() or \Drupal::service() names them.
• Typed lookups. \Drupal::service('entity_type.manager') and $container->get(…) are typed by the class the service is built from; a lookup by ::class is typed as that class or interface.
• Rename leaves core and contributed extensions alone, as it does vendor code, and refuses a namespace move that would leave them behind.
• Other frameworks unchanged. A Drupal site in the same workspace as a Symfony, Laravel or WordPress project leaves their behaviour as it was; tests cover the mixed workspace.

On drupal/redirect and drupal/flag, typed services remove three false positives and expose a few correct errors that untyped lookups hid.

A refactor in the first commit

The first commit, "String-key kinds name their framework through one exhaustive match", changes no behaviour.

Today. Four call sites decide which framework a string key belongs to with an if-chain, each in its own order. A kind that no check catches silently falls through to Laravel:

if kind.is_twig() {
    is_twig
} else if kind.is_yii() {
    is_yii
} else if kind.is_symfony() {
    is_symfony
} else {
    is_laravel
}

Why Drupal needs a change. Drupal uses Symfony's service container keys, but none of Symfony's routes, translations or events. With the chains, that means a new check placed before is_symfony() in all four chains, and a wrong order fails silently.

After. Each kind names its framework once, in a match with no catch-all, and every call site becomes a flat match:

match kind.framework() {
    KeyFramework::Laravel => is_laravel,
    KeyFramework::ServiceContainer | KeyFramework::Symfony => is_symfony,
    KeyFramework::Twig => is_twig,
    KeyFramework::Yii => is_yii,
    KeyFramework::WordPress => false,
}

A new kind that is not placed now fails to compile instead of becoming Laravel. WordPress, Twig and Middleware keys keep their current behaviour; every caller was traced to confirm it.

What DR2 then changes. A later commit gives the container keys their own switch, which is on in both Symfony and Drupal projects, without touching the other arms:

match kind.framework() {
    KeyFramework::Laravel => is_laravel,
    KeyFramework::ServiceContainer => reads_container,
    KeyFramework::Symfony => is_symfony,
    KeyFramework::Twig => is_twig,
    KeyFramework::Yii => is_yii,
    KeyFramework::WordPress => false,
}

The Drupal entity types PR adds a KeyFramework::Drupal arm the same way.

In Zed, the parts that start in a YAML or Twig file need zed-extensions/php#155; other editors already send those files to PHPantom.

Builds on #532.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, examples/)
• I have updated the config schema (config-schema.json). Not applicable: this PR adds or changes no setting.
• I have added/updated tests to cover my changes
• If I used AI tools, I have reviewed what they produced and can explain
  the changes and why they are needed.
• I have read through any AI-generated text, especially documentation,
  the changelog, and other user-facing content, and removed or corrected
  anything inaccurate, unclear, or unnecessary.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 98.98580% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/drupal/mod.rs	97.56%	2 Missing ⚠️
src/indexing/init.rs	96.42%	1 Missing ⚠️
src/reference_index.rs	87.50%	1 Missing ⚠️
src/symbol_map/extraction/symfony.rs	98.38%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[AJenbo]

Thanks