Skip to content
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

make const_err a future incompat lint #80394

Merged
merged 1 commit into from
Feb 3, 2021

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Dec 26, 2020

This is the first step for #71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong.

This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a hard error (at that point the error-on-use-site can be turned into a delay_span_bug! for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts).

The one annoying effect of this PR is that let _x = &(1/(1-1)); now also shows the future-incompat warning, even though of course we will not make this a hard error. We'll instead (hopefully) stop promoting it -- see rust-lang/rfcs#3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".

Cc @rust-lang/wg-const-eval

@rust-highfive
Copy link
Collaborator

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 26, 2020
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-9 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
.................................................................................................... 9000/11200
.................................................................................................... 9100/11200
..........................................................................................i......i.. 9200/11200
.................................................................................................... 9300/11200
.............................iiiiii..iiiiii.i....................................................... 9400/11200
.................................................................................................... 9600/11200
.................................................................................................... 9700/11200
.................................................................................................... 9800/11200
.................................................................................................... 9900/11200
---

---- [ui] ui/error-codes/E0396-fixed.rs stdout ----
diff of stderr:

7    |                            unable to turn bytes into a pointer
8    |
9    = note: `#[deny(const_err)]` on by default
+    = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>
10 
11 error: aborting due to previous error
12 
12 


The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/error-codes/E0396-fixed/E0396-fixed.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args error-codes/E0396-fixed.rs`
error: 1 errors occurred comparing output.
status: exit code: 1
status: exit code: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/error-codes/E0396-fixed.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zemit-future-incompat-report" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/error-codes/E0396-fixed" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/error-codes/E0396-fixed/auxiliary"
------------------------------------------

------------------------------------------
stderr:
stderr:
------------------------------------------
error: any use of this value will cause an error
   |
   |
LL | const VALUE: u8 = unsafe { *REG_ADDR };
   |                            |
   |                            |
   |                            unable to turn bytes into a pointer
   |
   = note: `#[deny(const_err)]` on by default
   = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>

error: aborting due to previous error

---

Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu


command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-9/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "9.0.0" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver engine executionengine fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcjit passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"


failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --exclude src/tools/tidy
Build completed unsuccessfully in 0:15:59

@ehuss
Copy link
Contributor

ehuss commented Dec 26, 2020

@RalfJung Can you say more why the old documentation was wrong? I was trying to distill RFC 1229 into a few short sentences, and I thought it captured the essence that this lint exists to handle backwards compatibility for new checks and errors added to the const evaluator (particularly for non-const contexts). The example code was also written to try to emphasize that fact.

Can you also include a link in the docs for the future-incompat issue? It is not added automatically in the documentation, so you have to add something like See [issue #71800](https://github.com/rust-lang/rust/issues/71800) for more details..

@oli-obk
Copy link
Contributor

oli-obk commented Dec 26, 2020

The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".

That seems like the right way forward, but I'm ok with erroneously mentioning that we're going to hard error this in the future even if we know we won't

@RalfJung
Copy link
Member Author

Can you say more why the old documentation was wrong? I was trying to distill RFC 1229 into a few short sentences, and I thought it captured the essence that this lint exists to handle backwards compatibility for new checks and errors added to the const evaluator (particularly for non-const contexts). The example code was also written to try to emphasize that fact.

The thing is, the const_err lint wasn't about anything related to backwards compatibility -- not since unconditional_panic and arithmetic_overflow have been moved to their own lints. const_err is about errors occurring when evaluating a const that wasn't used -- for const that are used, there's no choice but raise a hard error when there is an evaluation error.

The confusing bit here is related to what I said above about &(1/(1-1)): promotion turns this into a constant that fails to evaluate, so this also raises const_err. But IMO the fix here is to stop promoting this, see rust-lang/rfcs#3027.

Can you also include a link in the docs for the future-incompat issue? It is not added automatically in the documentation, so you have to add something like See issue #71800 for more details..

Thanks, will do.

@bors
Copy link
Contributor

bors commented Jan 1, 2021

☔ The latest upstream changes (presumably #80539) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung
Copy link
Member Author

RalfJung commented Jan 1, 2021

The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".

That seems like the right way forward, but I'm ok with erroneously mentioning that we're going to hard error this in the future even if we know we won't

Alternatively, these errors should disappear when/if #80579 lands.

@RalfJung RalfJung added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Jan 1, 2021
@RalfJung
Copy link
Member Author

RalfJung commented Jan 1, 2021

Nominating for lang team discussion to get signoff on the plan to make const_err a future-incompat lint (and eventually a hard error). See #71800 for some prior discussion.

Cc @rust-lang/lang

@Mark-Simulacrum
Copy link
Member

We discussed this in today's lang team meeting, and wanted to write up a comment and then discuss again so that we could better understand the trajectory and overall context here.

I've re-read the associated tracking issue (#71800), and I want to first summarize what const_err is about: const_err lints on entirely unused consts, intending to help crate authors who declare consts which could not be referenced by downstream code; it has no impact on generated code as these constants are already a hard error to use.

This PR implements the first step towards making failure to evaluate a const a hard error in the compiler by moving this lint to a future compatible lint (it is already deny-by-default). The expected impact is low, as the majority of crates do not allow this lint (since declaring a constant that errors on evaluation, but not wanting compilation to stop, is quite odd).

This PR, when originally written, has some undesirable error message implications due to touching on promoted consts which end up unused, but once #80579 lands, that will not be the case; T-lang also discussed that PR today and came to the conclusion that we would like to merge it so it is no longer a concern here.

@RalfJung - does this comment sound accurate? If so, I would expect lang to just approve this next week; I do not think an FCP is needed as future incompatibility is not committing us to anything.

@RalfJung
Copy link
Member Author

RalfJung commented Jan 13, 2021

const_err lints on entirely unused consts, intending to help crate authors who declare consts which could not be referenced by downstream code; it has no impact on generated code as these constants are already a hard error to use.

Well... not entirely. const_err lints on all consts that fail to evaluate in their CTFE query. For consts that are actually used somewhere, we additionally emit a brief hard error "use of invalid const" (and there is no choice here, we cannot compile this code). We have to emit this hard error in case the user did allow(const_err).

Naively, entirely unused consts would never even have their query fired, but to make sure the user is aware of possible issues with unused consts, there is a lint pass which simply triggers the CTFE query for all consts, used or not. This ensures even unused consts have the lint emitted -- they do not get the hard error though.

The goal is that once const_err is a hard error, we can adjust the code where consts are used to not emit another error/lint, but to simply bug! or delay_span_bug as appropriate. This will also solve issues like #65597.

This PR implements the first step towards making failure to evaluate a const a hard error in the compiler by moving this lint to a future compatible lint (it is already deny-by-default). The expected impact is low, as the majority of crates do not allow this lint (since declaring a constant that errors on evaluation, but not wanting compilation to stop, is quite odd).

Correct.

does this comment sound accurate?

Modulo the correction above, it does.

@RalfJung
Copy link
Member Author

The one annoying effect of this PR is that let _x = &(1/(1-1)); now also shows the future-incompat warning, even though of course we will not make this a hard error.

This is resolved now that #80579 and #81333 landed. So there are no more "false future-compat positives".

@RalfJung RalfJung force-pushed the const-err-future branch 2 times, most recently from f595fbd to 4fa4b84 Compare January 30, 2021 14:02
@oli-obk
Copy link
Contributor

oli-obk commented Jan 30, 2021

r=me after a rebase

@bors p=1 very bitrotty

@RalfJung
Copy link
Member Author

I think T-lang still needs to approve; the last status is

I would expect lang to just approve this next week; I do not think an FCP is needed as future incompatibility is not committing us to anything.

@joshtriplett
Copy link
Member

We reviewed this in today's @rust-lang/lang meeting, and we agreed that we approve this change.

Please go ahead and merge as soon as the merge conflicts are addressed.

@RalfJung
Copy link
Member Author

RalfJung commented Feb 3, 2021

@bors r=oli-obk

@bors
Copy link
Contributor

bors commented Feb 3, 2021

📌 Commit 8477d35 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 3, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 3, 2021
Rollup of 5 pull requests

Successful merges:

 - rust-lang#80394 (make const_err a future incompat lint)
 - rust-lang#81532 (Remove incorrect `delay_span_bug`)
 - rust-lang#81692 (Update clippy)
 - rust-lang#81715 (Reduce tab formatting assertions to debug only)
 - rust-lang#81716 (Fix non-existent-field ICE for generic fields.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 00dabfb into rust-lang:master Feb 3, 2021
@rustbot rustbot added this to the 1.51.0 milestone Feb 3, 2021
@bors
Copy link
Contributor

bors commented Feb 3, 2021

⌛ Testing commit 8477d35 with merge 120b2a7...

@RalfJung RalfJung deleted the const-err-future branch February 9, 2021 16:05
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 18, 2021
make UB during CTFE a hard error

This is a next step for rust-lang#71800. `const_err` has been a future-incompatibility lint for 4 months now since rust-lang#80394 (and err-by-default for many years before that), so I think we could try making it a proper hard error at least in some situations.

I didn't yet adjust the tests, since I first want to gauge the fall-out via crater.
Cc `@rust-lang/wg-const-eval`
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Jun 25, 2022
… r=estebank

make const_err show up in future breakage reports

As tracked in rust-lang#71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since rust-lang#80394 (landed more than a year ago). Some CTFE errors are already hard errors since rust-lang#86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.

Cc `@rust-lang/wg-const-eval`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 26, 2022
… r=estebank

make const_err show up in future breakage reports

As tracked in rust-lang#71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since rust-lang#80394 (landed more than a year ago). Some CTFE errors are already hard errors since rust-lang#86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.

Cc `@rust-lang/wg-const-eval`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 26, 2022
… r=estebank

make const_err show up in future breakage reports

As tracked in rust-lang#71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since rust-lang#80394 (landed more than a year ago). Some CTFE errors are already hard errors since rust-lang#86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.

Cc ``@rust-lang/wg-const-eval``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2022
… r=estebank

make const_err show up in future breakage reports

As tracked in rust-lang#71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since rust-lang#80394 (landed more than a year ago). Some CTFE errors are already hard errors since rust-lang#86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.

Cc ```@rust-lang/wg-const-eval```
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2022
… r=estebank

make const_err show up in future breakage reports

As tracked in rust-lang#71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since rust-lang#80394 (landed more than a year ago). Some CTFE errors are already hard errors since rust-lang#86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.

Cc ````@rust-lang/wg-const-eval````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2022
… r=estebank

make const_err show up in future breakage reports

As tracked in rust-lang#71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since rust-lang#80394 (landed more than a year ago). Some CTFE errors are already hard errors since rust-lang#86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.

Cc `````@rust-lang/wg-const-eval`````
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 7, 2022
make const_err a hard error

This lint has been deny-by-default with future incompat wording since [Rust 1.51](rust-lang#80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)

r? `@oli-obk`
Fixes rust-lang#71800
Fixes rust-lang#100114
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Oct 9, 2022
make const_err a hard error

This lint has been deny-by-default with future incompat wording since [Rust 1.51](rust-lang/rust#80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)

r? `@oli-obk`
Fixes rust-lang/rust#71800
Fixes rust-lang/rust#100114
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request Oct 20, 2022
make const_err a hard error

This lint has been deny-by-default with future incompat wording since [Rust 1.51](rust-lang/rust#80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)

r? `@oli-obk`
Fixes rust-lang/rust#71800
Fixes rust-lang/rust#100114
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
make const_err a hard error

This lint has been deny-by-default with future incompat wording since [Rust 1.51](rust-lang/rust#80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)

r? `@oli-obk`
Fixes rust-lang/rust#71800
Fixes rust-lang/rust#100114
linyihai pushed a commit to linyihai/rust-clippy that referenced this pull request Oct 23, 2023
同步社区最新master分支代码

Created-by: lizheng 30020856
Author-id: 11958
MR-id: 457385
Commit-by: bors;Michael Krasnitski;Mara Bos;KaDiWa;Alex Macleod;Manish Goregaokar;Tyler Weaver;Niki4tap;koka;Sylvain Desodt;ksaleem;Philipp Krones;Collin Styles;xFrednet;Martin Fischer;Evan Typanski;Vincenzo Palazzo;Samuel Moelius;chansuke;Michael Woerister;Kyle Matsuda;Maria José Solano;Michael Goulet;Yuki Okushi;Jason Newcomb;Joshua Nelson;Oli Scherer;Robert Bastian;navh;asquared31415;Andre Bogus;Albert Larsan;dswij;Raiki Tamura;Caio;blyxyas;Robin Schroer;Kyle Huey;Eric Wu;Nilstrieb;Andy Russell;Max Baumann;Ardis Lu;Trevor Gross;Ray Redondo;Matthias Krüger;Esteban Küber;Lukas Lueg;alexey semenyuk;dboso;Samuel Tardieu;feniljain;Gary Guo;Nicholas Nethercote;Fridtjof Stoldt;naosense;alex-semenyuk;Taiki Endo;Hannah Town;Jakob Degen;Lukas Wirth;Vadim Petrochenkov;mdgaziur;Eric Huss;Yuri Astrakhan;kraktus;Ralf Jung;Santiago Pastorino;Camille GILLOT;hkalbasi;Arpad Borsos;Maybe Waffle;ozkanonur;Sosthène Guédon;Deadbeef;Kartavya Vashishtha;Aphek;Nadir Fejzic;Lukas Markeffsky;hrxi;clubby789;yukang;Ryan Scheidter;Grachev Mikhail;Elliot Bobrow;Dylan DPC;Steven Casper;bebecue;Trevor Arjeski;Onur Özkan;Cameron Steffen;Guillaume Gomez;Matthew Ingwersen;Alex ✨ Cosmic Princess ✨;dswijj;mejrs;Rageking8;Alex;est31;oxalica;JT;Doru-Florin Blanzeanu;Andreu Botella;royrustdev;flip1995;lcnr;Kevin Per;Josh Stone;TennyZhuang;Marijn Schouten;Steven Nguyen;Cody;Urgau;ouz-a;Nahua Kang;Felix Kohlgrüber
Merged-by: wangqilin 00349210
E2E-issues: 
Description:
add syntax-tree-patterns RFC,
Remove if_chain from equatable_if_let,
Lint suggests matches macro if PartialEq trait is not implemented,
Run cargo dev bless to update fixes & stderr,
Merge commit 'ac0e10aa68325235069a842f47499852b2dee79e' into clippyup,
Remove `mir::CastKind::Misc`,
Merge commit '8f1ebdd18bdecc621f16baaf779898cc08cc2766' into clippyup,
Introduce TypeErrCtxt

TypeErrCtxt optionally has a TypeckResults so that InferCtxt doesn't
need to.,
Change InferCtxtBuilder from enter to build,
make const_err a hard error,
Auto merge of #102091 - RalfJung:const_err, r=oli-obk

make const_err a hard error

This lint has been deny-by-default with future incompat wording since [Rust 1.51](rust-lang/rust#80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)

r? `@oli-obk`
Fixes rust-lang/rust#71800
Fixes rust-lang/rust#100114,
Auto merge of rust-lang#2583 - RalfJung:rustup, r=oli-obk

initial josh subtree sync

This demonstrates what a josh-based rustup would look like with my patched josh. To create it I did
```
git fetch http://localhost:8000/rust-lang/rust.git:start=75dd959a3a40eb5b4574f8d2e23aa6efbeb33573[:prefix=src/tools/miri]:/src/tools/miri.git master
git merge FETCH_HEAD
./rustup-toolchain HEAD && ./miri fmt
git commit -am rustup
```
Unlike the [previous attempt](rust-lang/miri#2554), this does not add a new root commit to the repo.

Once we merge this, we committed to using josh for subtree syncing, and in particular a version of josh that includes josh-project/josh#961 (or something compatible).,
Stabilize half_open_range_patterns,
Rollup merge of #102675 - ouz-a:mir-technical-debt, r=oli-obk

Remove `mir::CastKind::Misc`

As discussed in #97649 `mir::CastKind::Misc` is not clear, this PR addresses that by creating a new enum variant for every valid cast.

r? ````@oli-obk````,
[`unnecessary_cast`] Do not lint negative hexadecimal literals when cast as float

Floats cannot be expressed as hexadecimal literals,
ImplItemKind::TyAlias => ImplItemKind::Type,
merge rustc history,
Fix clippy tests that trigger `for_loop_over_fallibles` lint,
fixup lint name,
deprecate `clippy::for_loops_over_fallibles`,
Rollup merge of #102829 - compiler-errors:rename-impl-item-kind, r=TaKO8Ki

rename `ImplItemKind::TyAlias` to `ImplItemKind::Type`

The naming of this variant seems inconsistent given that this is not really a "type alias", and the associated type variant for `TraitItemKind` is just called `Type`.,
Rollup merge of #102275 - Urgau:stabilize-half_open_range_patterns, r=cjgillot

Stabilize `half_open_range_patterns`

This PR stabilize `feature(half_open_range_patterns)`:
```
Allows using `..=X` as a pattern.
```

And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, rust-lang/rust#102275 (comment).

The FCP was completed in rust-lang/rust#67264.,
Rename AssocItemKind::TyAlias to AssocItemKind::Type,
Rollup merge of #99696 - WaffleLapkin:uplift, r=fee1-dead

Uplift `clippy::for_loops_over_fallibles` lint into rustc

This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.

There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
   ```rust
    for _ in iter.next() {}
    // turns into
    for _ in iter.by_ref() {}
    ```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
   ```rust
   for _ in rx.recv() {}
   // turns into
   while let Some(_) = rx.recv() {}
   ```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
   ```rust
   for _ in f() {}
   // turns into
   for _ in f()? {}
   ```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
   ```rust
   for _ in f() {}
   // turns into
   if let Some(_) = f() {}
   ```
(P.S. `Some` and `Ok` are interchangeable depending on the type)

I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!

Resolves #99272

[`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles,
Rollup merge of #102868 - compiler-errors:rename-assoc-tyalias-to-ty, r=TaKO8Ki

Rename `AssocItemKind::TyAlias` to `AssocItemKind::Type`

Thanks `@camsteffen` for catching this in ast too, cc rust-lang/rust#102829 (comment),
merge rustc history,
Fix unclosed HTML tag in clippy doc,
fix `box-default` ignoring trait objects' types,
Fix allow_attributes_without_reason applying to external crate macros

Previously the `clippy::allow_attributes_without_reason` lint would
apply to external crate macros. Many macros in the Rust ecosystem
include these `allow` attributes without adding a reason, making this
lint pretty much unusable in any sizable Rust project.

This commit fixes that by adding a check to the lint if the attribute is
from an external crate macro and returning early.,
Fix bug in `referent_used_exactly_once`,
merge rustc history,
`default_numeric_fallback` do not lint on constants,
refactor `default_numeric_fallback`

We only need to store if the literal binding has an explicit type bound or not,
Book: Small grammar + link a11y change,
Remove CastCheckResult since it's unused,
add missing comma,
Auto merge of rust-lang#9644 - hkBst:patch-1, r=flip1995

add missing comma

changelog: none,
Auto merge of rust-lang#9643 - icecream17:patch-1, r=flip1995

Book: Small grammar + link a11y change

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: none

---

Very minor

For the link accessibility change, `here` and related don't provide context for screen readers who are reading a list of links.
(Random supporting google links)
https://www.w3.org/QA/Tips/noClickHere
https://usability.yale.edu/web-accessibility/articles/links,
Don't lint `ptr_arg` when used as an incompatible trait object,
Auto merge of rust-lang#9645 - Jarcho:ptr_arg_9542, r=llogiq

Don't lint `ptr_arg` when used as an incompatible trait object

fixes rust-lang#9542
changelog: [`ptr_arg`](https://rust-lang.github.io/rust-clippy/master/#ptr_arg): Don't lint when used as an incompatible trait object,
Add a suggestion and a note about orphan rules for `from_over_into`,
Auto merge of rust-lang#9649 - Alexendoo:from-over-into-suggestion, r=llogiq

Add a suggestion and a note about orphan rules for `from_over_into`

Adds a machine applicable suggestion to convert the `Into` impl into a `From` one to `from_over_into`

Also adds a note explaining that `impl From<Local> for Foreign` is fine if the `Into` type is foreign

Closes rust-lang#7444
Addresses half of rust-lang#9638

changelog: [`from_over_into`] Add a suggestion and a note about orphan rules,
Separate internal lints by pass,
Move some things around,
Expand `unnecessary_def_path` lint,
Fix adjacent code,
Format affected files,
`explicit_ty_bound` code golf,
[`zero_prefixed_literal`] Do not advise to use octal form if not possible,
Enable test no_std_main_recursion,
fix `box-default` linting `no_std` non-boxes,
Auto merge of rust-lang#9655 - llogiq:unbox-default, r=dswij

fix `box-default` linting `no_std` non-boxes

This fixes rust-lang#9653 by doing the check against the `Box` type correctly even if `Box` isn't there, as in `no_std` code. Thanks to `@lukas-code` for opening the issue and supplying a reproducer!

---

changelog: none,
Auto merge of rust-lang#9636 - kraktus:numeric-fallback, r=dswij

[`default_numeric_fallback`] do not lint on constants

fix rust-lang#9632

changelog:[`default_numeric_fallback`] do not lint on constants,
Auto merge of rust-lang#9566 - smoelius:diagnostic-item-path, r=dswij

Expand internal lint `unnecessary_def_path`

This PR does essentially two things:
* Separates the internal lints into modules by pass. (`internal_lints.rs` was over 1400 lines, which is a little unruly IMHO.)
* ~Adds a new~ Expands the `unnecessary_def_path` internal lint to flag hardcoded paths to diagnostic and language items.

My understanding is that the latter is currently done by reviewers. Automating this process should make things easier for both reviewers and contributors.

I could make the first bullet a separate PR, or remove it entirely, if desired.

changelog: Add internal lint `diagnostic_item_path`,
Add new lint `partial_pub_fields`

Signed-off-by: TennyZhuang <zty0826@gmail.com>,
fix dogfood

Signed-off-by: TennyZhuang <zty0826@gmail.com>,
add many tests

Signed-off-by: TennyZhuang <zty0826@gmail.com>,
fix a doctest

Signed-off-by: TennyZhuang <zty0826@gmail.com>,
Auto merge of rust-lang#9658 - TennyZhuang:partial-pub-fields, r=llogiq

Add new lint `partial_pub_fields`

Signed-off-by: TennyZhuang <zty0826@gmail.com>

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: `partial_pub_fields`: new lint to disallow partial fields of a struct be pub

Resolve rust-lang#9604,
Auto merge of rust-lang#9652 - kraktus:octo_89, r=xFrednet

[`zero_prefixed_literal`] Do not advise to use octal form if not possible

fix rust-lang#9651

changelog: [`zero_prefixed_literal`] Do not advise to use octal form if not possible,
Auto merge of rust-lang#9609 - kraktus:hexa_f32, r=giraffate

[`unnecessary_cast`] Do not lint negative he

See merge request innersource/rust/toolset/rust-clippy!8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants