-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
…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.
46276c8
to
916e404
Compare
@rustbot ready Note that I've also added a test that |
But they did work, for incremental scenarios? Just not for cargo rebuilds. |
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.
5db8102
to
6ca63b3
Compare
@rustbot ready
I think so. I've brought them back. |
This comment has been minimized.
This comment has been minimized.
c89fbb7
to
745b34e
Compare
This comment has been minimized.
This comment has been minimized.
745b34e
to
1028b1e
Compare
This comment has been minimized.
This comment has been minimized.
1028b1e
to
aa575ad
Compare
This comment has been minimized.
This comment has been minimized.
compiler/rustc_borrowck/src/nll.rs
Outdated
let algorithm = infcx | ||
.tcx | ||
.env_var_os("POLONIUS_ALGORITHM".as_ref()) | ||
.unwrap_or_else(|| Symbol::intern("Hybrid")); |
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 think a better solution here would be to add a polonius_algorithm
field to Options
and read the POLONIUS_ALGORITHM
env var in build_session_options
. Then marking the field as [TRACKED]
is enough to get it tracked by incr comp.
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.
That is exactly what I did originally in #129342, but @petrochenkov preferred that we integrated it with the query system instead, hence this PR.
I have no idea what's the best solution here, I'll defer to you two to discuss and decide on that ;) .
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 did prefer accessing env vars as early as possible to prevent eg proc-macros from affecting compilation options. Proc-macros are known to do things they should not be allowed to do.
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.
Having a query for env vars probably still makes sense even if some of the env var uses are converted to options.
(One downside of early tracking is that the dependency on the env var will be registered even if the env var is not actually used.)
aa575ad
to
2b561b8
Compare
This won't work with Cargo's change tracking, but it should work with incremental.
2b561b8
to
60f18ba
Compare
@@ -29,3 +34,13 @@ impl std::ops::Deref for Providers { | |||
&self.queries | |||
} | |||
} | |||
|
|||
impl<'tcx> TyCtxt<'tcx> { |
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.
Maybe put it to compiler\rustc_middle\src\ty\context.rs
?
That's where TyCtxt
is defined and many of its random inherent methods live.
@@ -29,3 +34,13 @@ impl std::ops::Deref for Providers { | |||
&self.queries | |||
} | |||
} | |||
|
|||
impl<'tcx> TyCtxt<'tcx> { | |||
pub fn env_var(self, key: &'tcx OsStr) -> Result<&'tcx str, VarError> { |
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.
Can use AsRef<OsStr>
here, then the function will accept string literals.
You even use key.as_ref()
below, which is unnecessary if the key is a non-generic OsStr
.
|
||
impl<'tcx> TyCtxt<'tcx> { | ||
pub fn env_var(self, key: &'tcx OsStr) -> Result<&'tcx str, VarError> { | ||
if let Some(value) = self.env_var_os(key.as_ref()) { |
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.
Style nit: if-lets with short (one line) arms typically look better as a match.
} | ||
} | ||
|
||
impl<'tcx> Key for Option<&'tcx OsStr> { |
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 this necessary?
Option<&'tcx OsStr>
doesn't seem to be used as a key.
@@ -255,6 +264,7 @@ trivial! { | |||
Option<rustc_span::def_id::DefId>, | |||
Option<rustc_span::def_id::LocalDefId>, | |||
Option<rustc_span::Span>, | |||
Option<rustc_span::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.
This is likely not necessary anymore.
@@ -180,6 +185,10 @@ impl<T> EraseType for Option<&'_ [T]> { | |||
type Result = [u8; size_of::<Option<&'static [()]>>()]; | |||
} | |||
|
|||
impl EraseType for Option<&'_ OsStr> { |
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.
Probably unnecessary.
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