Use the correct span when emitting the env! result
#117592
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
davidtwco
approved these changes
Nov 6, 2023
|
@bors r+ |
bors
added
S-waiting-on-bors
|
@bors rollup |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 6, 2023
Use the correct span when emitting the `env!` result The span used for the `env!` resut changed in 1.73, due to rust-lang@75df62d (from rust-lang#114014). This prevents [a lint in `plrustc`](https://github.com/tcdi/plrust/blob/main/plrustc/plrustc/src/lints/builtin_macros.rs#L54-L60)[^1] from working well, because the resulting span is not inside the region where the lint is `#[deny()]`ed. [^1]: Perhaps worth noting that the `env_macro` diagnostic item comes from [the std fork used with PL/Rust](https://github.com/tcdi/postgrestd/blob/rust-1.73.0/library/core/src/macros/mod.rs#L944). Unfortunately, I have no idea how to write a test for this since I don't think we can have a custom lint in a test. A suggestion was made to use a custom proc macro for it, but that seems pretty involved (frankly, I might not have time to do it). r? `@davidtwco` (since they're the author of the PR with the regression) P.S. We generally try to avoid bothering upstream about PL/Rust-specific stuff (we don't want to nag), but this seems like an actual bug, since the other similar macros, such as `option_env` use the other span (and are lintable as a result).
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 6, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#117578 (Derive `TyEncodable`/`TyDecodable` in `rustc_type_ir`) - rust-lang#117592 (Use the correct span when emitting the `env!` result) - rust-lang#117609 (Distinguish crates with the same name in type errors) - rust-lang#117613 (Remove from vacation and compiler review group) - rust-lang#117615 (Couple of small changes) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 6, 2023
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#117592 (Use the correct span when emitting the `env!` result) - rust-lang#117613 (Remove from vacation and compiler review group) - rust-lang#117615 (Couple of small changes) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 6, 2023
Rollup merge of rust-lang#117592 - thomcc:env-span-wrong, r=davidtwco Use the correct span when emitting the `env!` result The span used for the `env!` resut changed in 1.73, due to rust-lang@75df62d (from rust-lang#114014). This prevents [a lint in `plrustc`](https://github.com/tcdi/plrust/blob/main/plrustc/plrustc/src/lints/builtin_macros.rs#L54-L60)[^1] from working well, because the resulting span is not inside the region where the lint is `#[deny()]`ed. [^1]: Perhaps worth noting that the `env_macro` diagnostic item comes from [the std fork used with PL/Rust](https://github.com/tcdi/postgrestd/blob/rust-1.73.0/library/core/src/macros/mod.rs#L944). Unfortunately, I have no idea how to write a test for this since I don't think we can have a custom lint in a test. A suggestion was made to use a custom proc macro for it, but that seems pretty involved (frankly, I might not have time to do it). r? ``@davidtwco`` (since they're the author of the PR with the regression) P.S. We generally try to avoid bothering upstream about PL/Rust-specific stuff (we don't want to nag), but this seems like an actual bug, since the other similar macros, such as `option_env` use the other span (and are lintable as a result).
bors-ferrocene bot
added a commit
to ferrocene/ferrocene
that referenced
this pull request
Nov 7, 2023
89: Automated pull from upstream `master` r=Dajamante a=github-actions[bot] This PR pulls the following changes from the upstream repository: * rust-lang/rust#117006 * rust-lang/rust#117511 * rust-lang/rust#117641 * rust-lang/rust#117637 * rust-lang/rust#117631 * rust-lang/rust#117516 * rust-lang/rust#117190 * rust-lang/rust#117292 * rust-lang/rust#117603 * rust-lang/rust#116988 * rust-lang/rust#117630 * rust-lang/rust#117615 * rust-lang/rust#117613 * rust-lang/rust#117592 * rust-lang/rust#117578 * rust-lang/rust#117435 * rust-lang/rust#117607 90: bump serde and serde_derive r=tshepang a=Dajamante Trying to get around the failure seen in #86 Co-authored-by: Ralf Jung <post@ralfj.de> Co-authored-by: Esteban Küber <esteban@kuber.com.ar> Co-authored-by: SparrowLii <liyuan179@huawei.com> Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de> Co-authored-by: Gurinder Singh <frederick.the.fool@gmail.com> Co-authored-by: Michael Goulet <michael@errs.io> Co-authored-by: Thom Chiovoloni <thom@shift.click> Co-authored-by: klensy <klensy@users.noreply.github.com> Co-authored-by: Jack Huey <31162821+jackh726@users.noreply.github.com> Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com> Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Sven Marnach <sven@mozilla.com> Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com> Co-authored-by: aissata <aimaiga2@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The span used for the
env!resut changed in 1.73, due to 75df62d (from #114014).This prevents a lint in
plrustc1 from working well, because the resulting span is not inside the region where the lint is#[deny()]ed.Unfortunately, I have no idea how to write a test for this since I don't think we can have a custom lint in a test. A suggestion was made to use a custom proc macro for it, but that seems pretty involved (frankly, I might not have time to do it).
r? @davidtwco (since they're the author of the PR with the regression)
P.S. We generally try to avoid bothering upstream about PL/Rust-specific stuff (we don't want to nag), but this seems like an actual bug, since the other similar macros, such as
option_envuse the other span (and are lintable as a result).Footnotes
Perhaps worth noting that the
env_macrodiagnostic item comes from the std fork used with PL/Rust. ↩