RA handling of config.toml is broken

[Jeremiah-Griffin]

OS: Win 11 Home 22H2 (22621.3880)
rustc version: 1.81.0-nightly (5affbb171 2024-07-18)
rust-analyzer version: 1.81.0-nightly (5affbb17 2024-07-18)
editor: helix 23.10 (f6021dd0)
relevant settings: .cargo/config.toml of linked repository

Rust Analyzer is seemingly inconsistently reading the [env] structure of config.toml, causing strange errors.

This repo replicates the issue using uuid and sqlx.

In brief, Rust-Analyzer seems to be running analysis of procedural macros twice: once with the environment variables set and once without.

This can be seen in shroedingers_connection.png which is a screenshot of the error returned by the commented out invocation of the query macro in main.

Rust analyzer both returns that correct error from the database - that table foo does not exist - while also claiming that no database connection could be established due to the DATABASE_URL variable being unset, despite it being set in cargo.toml. This is nonsensical as the sqlx::query macro must be able to connect to the database to capture such an error.

This also means that when these queries are successfully typechecked and can be compiled by rustc, RA returns the error claiming no database was found, without any sql error present. This is quite confusing.

So far, I've tracked the issue to nightly-2024-06-24. All versions including and following this that I have tested express the issue.

All versions before this have not.

[Jeremiah-Griffin]

@Veykril

Has #17697 landed on nightly yet? If so, the issue has not been fixed as I can still reproduce it both in the linked codebase and my proprietary one. Its expression is identical as well.

[Veykril]

Hmm, can you check the logs for ERROR entries? The linked repo works for me with the latest release

[Veykril]

Also for context, the issue here is/was that we ask cargo for the env entries via an unstable command so that we don't need to parse the toml file ourselves, cargo recently changed the output format of this though, breaking our parsing logic which no longer made us interpret the env var so when we expanded the proc-macro ourselves it was now missing the env var hence the diagnostic.