proc_macro: Add API for tracked access to environment variables

[petrochenkov]

Continuation of #71858.

proc_macro::tracked_env::var is similar to regular env::var called from a proc macro, except that it also adds the accessed variable to depinfo.

[rust-highfive]

@petrochenkov: no appropriate reviewer found, use r? to override

[petrochenkov]

r? @eddyb@Mark-Simulacrum

[Mark-Simulacrum]

❤️ Thank you for following through on this. cc @dtolnay to get libs sign-off on the unstable API.

[dtolnay]

Seems fine. Please file a tracking issue.

Some notes to address here or otherwise add to the tracking issue to address before stabilizing:

• Ideally the signature would match the function in std::env but I see that putting OsStr in depinfo is possibly hard. Don't filepaths go into depinfo though? Those are OS strings so what do we do there, and would it be possible to do that for here as well?

• If there is a possibility we want to expose some other things from std::env, maybe proc_macro::tracked_env::var would be more appropriate to keep those together.

[petrochenkov]

@dtolnay

Don't filepaths go into depinfo though?

They do, and they use lossy Path::display, so paths incompatible with UTF-8 are not treated correctly.

There's some discussion about non-UTF-8 cases in environment variables in #71858, looks like the general stance is that they don't matter.
FWIW, they can be added later as a new depinfo directive (e.g. # env-dep-bytes as opposed to existing # env-dep) with bytes printed in escaped form (like byte string literals).

Ideally the signature would match the function in std::env

I thought about the signature a bit, assuming we are keeping UTF-8, the alternatives to var: &str (which I've chosen as the simplest variant) could be:

pubfntracked_env_var(var:implAsRef<OsStr> + AsRef<str> + Copy) -> Result<String,VarError>{let value = env::var(var);// Need `Copy` to avoid consuming `var` here
bridge::client::FreeFunctions::track_env_var(var, value.as_deref().ok());
value
}

or

// Without `Copy`pubfntracked_env_var(var:implAsRef<OsStr> + AsRef<str>) -> Result<String,VarError>{let var = &var.to_string();// Have to convert into an owned stringlet value = env::var(var);
bridge::client::FreeFunctions::track_env_var(var, value.as_deref().ok());
value
}

The original env::var uses just impl AsRef<OsStr>.

[petrochenkov]

If there is a possibility we want to expose some other things from std::env, maybe proc_macro::tracked_env::var would be more appropriate to keep those together.

Yeah, sounds reasonable.

[dtolnay]

I would feel more comfortable with var: impl AsRef<OsStr> + AsRef<str>. That leaves the possibility to remove AsRef<str> bound backward compatibly to match the std::env::var signature.

[petrochenkov]

Updated.

• The function is moved into a module (tracked_env_var -> tracked_env::var).
• Tracking issue number is updated.
• The signature is changed to impl AsRef<OsStr> + AsRef<str>.
  r? @dtolnay

[dtolnay]

Looks good!

[dtolnay]

@bors r+

[bors]

📌 Commit 62c9fa9 has been approved by dtolnay

[bors]

⌛ Testing commit 62c9fa9 with merge 1841fb9...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: dtolnay
Pushing 1841fb9 to master...

[rust-highfive]

📣 Toolstate changed by #74653!

Tested on commit 1841fb9.
Direct link to PR: #74653

💔 rls on windows: test-pass → build-fail (cc @Xanewok).
💔 rls on linux: test-pass → build-fail (cc @Xanewok).
💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro@calebcartwright).
💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro@calebcartwright).