Change:
tts: TokenStream, name: &str, ) -> ExpandResult<Result<(Symbol, Span), ErrorGuaranteed>, ()> { <ins> let ExpandResult::Ready(ret) = get_single_expr_from_tts(cx, span, tts, name) else { return ExpandResult::Retry(()); }; let ret = match ret { Ok(ret) => ret, Err(e) => return ExpandResult::Ready(Err(e)), }; expr_to_spanned_string(cx, ret, "argument must be a string literal").map(|res| { res.map_err(|err| match err { Ok((err, _)) => err.emit(), Err(guar) => guar, }) .map(|(symbol, _style, span)| (symbol, span)) }) } /// Interpreting `tts` as a comma-separated sequence of expressions, /// expect exactly one expression, or emit an error and return `Err`. pub(crate) fn get_single_expr_from_tts( cx: &mut ExtCtxt<'_>, span: Span, tts: TokenStream, name: &str, ) -> ExpandResult<Result<P<ast::Expr>, ErrorGuaranteed>, ()> { </ins> let mut p = cx.new_parser_from_tts(tts); if p.token == token::Eof { let guar = cx.dcx().emit_err(errors::OnlyOneArgument { span, name });

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .