-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add environment variable query #130883
base: master
Are you sure you want to change the base?
Add environment variable query #130883
Conversation
@@ -336,6 +337,20 @@ fn early_lint_checks(tcx: TyCtxt<'_>, (): ()) { | |||
) | |||
} | |||
|
|||
fn env_var(tcx: TyCtxt<'_>, key: Symbol) -> Option<Symbol> { | |||
let var = match std::env::var(key.as_str()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there something similar to Clippy's disallowed-methods
that I could use to lint against usage of std::env::var
in the compiler, and direct users towards the query instead?
See also rust-lang/cargo#11588.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's some rustc-internal lints in https://github.com/rust-lang/rust/blob/master/compiler/rustc_lint/src/internal.rs
This comment has been minimized.
This comment has been minimized.
506b0df
to
af26a40
Compare
This comment has been minimized.
This comment has been minimized.
dee9b61
to
0ef9570
Compare
This comment has been minimized.
This comment has been minimized.
0ef9570
to
455e468
Compare
This comment has been minimized.
This comment has been minimized.
455e468
to
46276c8
Compare
// Also add the variable to Cargo's dependency tracking | ||
tcx.sess.psess.env_depinfo.borrow_mut().insert((key, var)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, a complication here is that this query will only work with the dependency info files that Cargo reads if it's called before passes::write_dep_info
at:
rust/compiler/rustc_driver_impl/src/lib.rs
Line 437 in a3f76a2
passes::write_dep_info(tcx); |
So everything done during passes::analysis
and Linker::codegen_and_build_linker
will need some other mechanism for populating ParseSess::env_depinfo
.
Is it possible for us to move the write_dep_info
pass to the very end, or just before linking? Or is it important that it happens as soon as possible for parallelizing Cargo, or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or is it important that it happens as soon as possible for parallelizing Cargo, or something?
It is important for depinfo to be generated as early as possible, without performing full compilation.
All file dependencies in particular, and env var dependencies from env!
and proc macros are ready after name resolution is completed.
I think it's fine to still lose some env depinfo in this PR, it will still better than what we have now.
Could you add a comment to this code, explaining that env vars added after the call to write_dep_info
will be lost from the dep file?
(We can think what to do with the Apple env vars specifically later.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a comment to the env_var
query, and added rustc_codegen_ssa::register_environment_variables
as an extension point for where to put this. Suggestions very welcome on how to do it differently!
/// detection and target-dependent compiler flags. | ||
/// | ||
/// Will emit an error and return `None` if the variable is not UTF-8. | ||
query env_var(key: Symbol) -> Option<Symbol> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to use OsStr(ing)
s in query inputs and outputs? What are the obstacles?
Many places in the compiler use env::var_os
.
Also, Symbol
s shouldn't be needed here, you can take a OsStr
/str
and return &'tcx OsString
/&'tcx String
like env::var(_os)
returns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OsStr
isn't really set up with the query system, so we'd have to do that first. I've done parts of it in the last commit, but it also needs to be Key
, which I'm unsure would be correct? str
for example isn't Key
either.
Also, returning &'tcx OsStr
requires that the environment variables are actually stored inside TyCtxt<'tcx>
, which I'm unsure how to do wrt. lifetimes?
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? `@petrochenkov`
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ```@petrochenkov```
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ````@petrochenkov````
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? `````@petrochenkov`````
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ``````@petrochenkov``````
Rollup merge of rust-lang#131037 - madsmtm:move-llvm-target-versioning, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ``````@petrochenkov``````
This comment was marked as resolved.
This comment was marked as resolved.
This currently works because it's part of expansion, and that isn't yet tracked by the query system. But we want to ensure it continues working, even if that is changed.
46276c8
to
916e404
Compare
@rustbot ready Note that I've also added a test that |
Generally,
rustc
prefers command-line arguments, but in some cases, an environment variable really is the most sensible option. We should make sure that this works properly with the compiler's change-tracking mechanisms, such that changing the relevant environment variable causes a rebuild.This PR is a first step forwards in doing that.
Part of the work needed to do #118204, see #129342 for some discussion.
r? @petrochenkov