make const_err a future incompat lint #80394

RalfJung · 2020-12-26T21:47:39Z

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 · 2020-12-26T21:47:44Z

r? @estebank

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

rust-log-analyzer · 2020-12-26T22:06:23Z

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 · 2020-12-26T22:25:56Z

@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 · 2020-12-26T23:43:59Z

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 · 2020-12-27T22:06:11Z

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 · 2021-01-01T10:59:49Z

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

RalfJung · 2021-01-01T14:19:06Z

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 · 2021-01-01T14:39:23Z

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 · 2021-01-12T23:19:07Z

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 · 2021-01-13T18:22:46Z

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 · 2021-01-30T13:51:35Z

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".

oli-obk · 2021-01-30T18:57:54Z

r=me after a rebase

@bors p=1 very bitrotty

RalfJung · 2021-01-30T20:16:21Z

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 · 2021-02-02T18:20:13Z

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 · 2021-02-03T16:25:31Z

@bors r=oli-obk

bors · 2021-02-03T16:25:33Z

📌 Commit 8477d35 has been approved by oli-obk

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 · 2021-02-03T20:53:03Z

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

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`

… 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`

… 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``

… 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```

… 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````

… 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`````

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

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

同步社区最新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

rust-highfive assigned estebank Dec 26, 2020

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

RalfJung mentioned this pull request Dec 26, 2020

"guessed cause of the failure" should include the list of failed tests rust-lang/rust-log-analyzer#55

Open

RalfJung force-pushed the const-err-future branch from a84c492 to 5c796d0 Compare December 26, 2020 22:11

RalfJung force-pushed the const-err-future branch from 5c796d0 to 633448d Compare December 27, 2020 22:09

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 force-pushed the const-err-future branch from 633448d to fa60f3d Compare January 30, 2021 13:49

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

make const_err a future incompat lint

8477d35

RalfJung force-pushed the const-err-future branch from 4fa4b84 to 8477d35 Compare February 3, 2021 14:45

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

m-ou-se mentioned this pull request Feb 3, 2021

Rollup of 5 pull requests #81718

Merged

bors merged commit 00dabfb into rust-lang:master Feb 3, 2021

rustbot added this to the 1.51.0 milestone Feb 3, 2021

m-ou-se mentioned this pull request Feb 3, 2021

miri no longer builds after rust-lang/rust#81718 #81726

Closed

RalfJung deleted the const-err-future branch February 9, 2021 16:05

RalfJung mentioned this pull request Jun 10, 2021

make UB during CTFE a hard error #86194

Merged

RalfJung mentioned this pull request Jun 4, 2022

make const_err show up in future breakage reports #97743

Merged

RalfJung mentioned this pull request Sep 22, 2022

make const_err a hard error #102091

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

make const_err a future incompat lint #80394

make const_err a future incompat lint #80394

RalfJung commented Dec 26, 2020 •

edited

Loading

rust-highfive commented Dec 26, 2020

rust-log-analyzer commented Dec 26, 2020

ehuss commented Dec 26, 2020

oli-obk commented Dec 26, 2020

RalfJung commented Dec 27, 2020

bors commented Jan 1, 2021

RalfJung commented Jan 1, 2021

RalfJung commented Jan 1, 2021

Mark-Simulacrum commented Jan 12, 2021

RalfJung commented Jan 13, 2021 •

edited

Loading

RalfJung commented Jan 30, 2021

oli-obk commented Jan 30, 2021

RalfJung commented Jan 30, 2021

joshtriplett commented Feb 2, 2021

RalfJung commented Feb 3, 2021

bors commented Feb 3, 2021

bors commented Feb 3, 2021

make const_err a future incompat lint #80394

make const_err a future incompat lint #80394

Conversation

RalfJung commented Dec 26, 2020 • edited Loading

rust-highfive commented Dec 26, 2020

rust-log-analyzer commented Dec 26, 2020

ehuss commented Dec 26, 2020

oli-obk commented Dec 26, 2020

RalfJung commented Dec 27, 2020

bors commented Jan 1, 2021

RalfJung commented Jan 1, 2021

RalfJung commented Jan 1, 2021

Mark-Simulacrum commented Jan 12, 2021

RalfJung commented Jan 13, 2021 • edited Loading

RalfJung commented Jan 30, 2021

oli-obk commented Jan 30, 2021

RalfJung commented Jan 30, 2021

joshtriplett commented Feb 2, 2021

RalfJung commented Feb 3, 2021

bors commented Feb 3, 2021

bors commented Feb 3, 2021

RalfJung commented Dec 26, 2020 •

edited

Loading

RalfJung commented Jan 13, 2021 •

edited

Loading