jiebi/CodeConvo huggingface dataset:
Change:
let cnum = cdata.cnum; assert!(cnum != LOCAL_CRATE); <del> // If this crate is a custom derive crate, then we're not even going to // link those in so we skip those crates. if cdata.root.macro_derive_registrar.is_some() { return Arc::new(Vec::new()) } </del> Arc::new(cdata.exported_symbols(tcx)) } }

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
inside_public_path: true, exact_paths: Default::default(), modules: vec![om], <ins> is_importable_from_parent: true, </ins> } }

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
|                  ~~~~~~~~ error: called `.get().unwrap()` on a slice <del> --> tests/ui/get_unwrap.rs:83:18 </del> <ins> --> tests/ui/get_unwrap.rs:84:18 </ins> | LL |         let _x = f.get(1 + 2).unwrap().abs(); |                  ^^^^^^^^^^^^^^^^^^^^^

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-102374.rs:16:5 | LL | ) -> i32 { |      --- expected `i32` because of return type LL |     f |     ^ expected `i32`, found fn pointer | = note:    expected type `i32` found fn pointer `for<'z1, 'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k, 'l, 'm, 'n, 'o, 'p, 'q, 'r, 's, 't, 'u, 'v, 'w, 'x, 'y, 'z, 'z0> fn(Cell<(&'z1 i32, &'a i32, &'b i32, &'c i32, &'d i32, &'e i32, &'f i32, &'g i32, &'h i32, &'i i32, &'j i32, &'k i32, &'l i32, &'m i32, &'n i32, &'o i32, &'p i32, &'q i32, &'r i32, &'s i32, &'t i32, &'u i32, &'v i32, &'w i32, &'x i32, &'y i32, &'z i32, &'z0 i32)>)` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
label regression-from-stable-to-nightly regression in , cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label A-diagnostics
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
use syntax::ast_util::{local_def}; use syntax::attr; use syntax::codemap::Span; <ins> use syntax::parse::token; </ins> use syntax::visit; use syntax::visit::Visitor;

Discussion:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.
Change:
} #[test] <ins> fn test_step_by_skip() { assert_eq!((0..640).step_by(128).skip(1).collect::<Vec<_>>(), [128, 256, 384, 512]); assert_eq!((0..=50).step_by(10).nth(3), Some(30)); assert_eq!((200..=255u8).step_by(10).nth(3), Some(230)); } #[test] </ins> fn test_range_inclusive_step() { assert_eq!((0..=50).step_by(10).collect::<Vec<_>>(), [0, 10, 20, 30, 40, 50]); assert_eq!((0..=5).step_by(1).collect::<Vec<_>>(), [0, 1, 2, 3, 4, 5]);

Discussion:
The following snippet demonstrates the problem: It prints: I expect second iterator to produce the same result as for the third one.
Regression from 1.28.0 to 1.29.0. Introduced in
The problem is interaction between and . ignores the inner working of StepBy. Test-case reduced to using without .
From a cursory look, it seems to me that the problem is that and are out of sync. StepBy specifically allows for the underlying iterator, either or . If both and follow the same one, the bug shouldn't occur. In other words, if is specialized and overrides the default, then needs to be specialized as well.
Change:
tcx: TyCtxt<'_>, closure_id: hir::HirId, ) -> bool { <ins> if tcx.sess.rust_2021() { return false; } </ins> let (level, _) = tcx.lint_level_at_node(lint::builtin::RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES, closure_id);

Discussion:
Given the following code: The current output is: Ideally the output should look like: The code is already being compiled for the 2021 edition, there's no need to issue any warnings about behaviour that was different in 2018. The compiler should assume that the code is working as expected. This might affect other warnings in the same category, I'm not sure. Tested in 1.63, beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
So, it seems that there are 3 warnings in this category and the issue only affects the closure one: is not affected because it checks that auto-ref happens, which doesn't in rust 2021 is not affected because the linted code simply doesn't compile in rust 2021 is affected
seems to be needed, because is marked with and the lint wants a significant impl MRE:
Change:
<ins> error[E0637]: `&` without an explicit lifetime name cannot be used here --> $DIR/ice-cannot-relate-region-109178.rs:7:31 | LL | struct Changes<const CHANGES: &[&'static str]> |                               ^ explicit lifetime name needed here error[E0637]: `&` without an explicit lifetime name cannot be used here --> $DIR/ice-cannot-relate-region-109178.rs:12:21 | LL | impl<const CHANGES: &[&str]> Changes<CHANGES> where [(); CHANGES.len()]: {} |                     ^ explicit lifetime name needed here error[E0637]: `&` without an explicit lifetime name cannot be used here --> $DIR/ice-cannot-relate-region-109178.rs:12:23 | LL | impl<const CHANGES: &[&str]> Changes<CHANGES> where [(); CHANGES.len()]: {} |                       ^ explicit lifetime name needed here error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0637`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched toolchains through Regression in
label +S-bug-has-mcve
Triage: the ICE has been fixed since nightly-2023-05-17. labels: +E-needs-test
Change:
<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that rustc doesn't crash on the trait bound `Self::Ty: std::marker::Freeze`. pub struct Struct; impl Struct { pub type Ty = usize; pub const CT: Self::Ty = 42; } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This might also be related to cc
label F-inherentassociatedtypes claim
Change:
&self.local.trait_cache } <del> pub fn max_obj_size(&self) -> u64 { 1<<31 /* FIXME #18069: select based on architecture */ </del> <ins> /// Return exclusive upper bound on object size. /// /// The theoretical maximum object size is defined as the maximum positive `int` value. This /// ensures that the `offset` semantics remain well-defined by allowing it to correctly index /// every address within an object along with one byte past the end, along with allowing `int` /// to store the difference between any two pointers into an object. /// /// The upper bound on 64-bit currently needs to be lower because LLVM uses a 64-bit integer to /// represent object size in bits. It would need to be 1 << 61 to account for this, but is /// currently conservatively bounded to 1 << 47 as that is enough to cover the current usable /// address space on 64-bit ARMv8 and x86_64. pub fn obj_size_bound(&self) -> u64 { match self.sess().target.target.target_word_size[] { "32" => 1 << 31, "64" => 1 << 47, _ => unreachable!() // error handled by config::build_target_config } </ins> } pub fn report_overbig_object(&self, obj: ty::t) -> ! {

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.
Change:
cat $(TMPDIR)/libs.txt | grep -F "systemd" # in foo.rs cat $(TMPDIR)/libs.txt | grep -F "bar_cli" cat $(TMPDIR)/libs.txt | grep -F "foo_cli" <ins> # make sure that foo_cli and glib-2.0 are not consecutively present cat $(TMPDIR)/libs.txt | grep -Fv "foo_cli -lfoo_cli" cat $(TMPDIR)/libs.txt | grep -Fv "glib-2.0 -lglib-2.0" </ins>

Discussion:
Hi there, In we use to try and keep our crate's linking instructions up-to-date across supported platforms. We've noticed that in some build configurations the output can change in surprising ways. For instance, using rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration driven by we see many consecutive duplicate libraries in the output. I understand duplicates are to be expected, and can be meaningful on some platforms, but seeing so many consecutive repeats seems unexpected and unlikely to be meaningful for the build process. Is this perhaps a regression? Or are we making a mistake by relying on the stability of this output across versions/build configurations? This feature is as having a known prefix to "make it easier to fetch the output." leading to the idea that it is expected to be machine consumable. I tried this code: I expected to see this happen: A list produced, with some duplicates (e.g. multiple ), but not many consecutive duplicates. E.g.: Instead, this happened: A list with many consecutive duplicates is produced: </detailsrustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. Project: Build task: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hm, I thought we usually removed consecutive duplicates but apparently only in release. A workaround would be to do so manually. For the msvc targets all duplicates can be removed so long as the order is preserved. This isn't true of many other targets though. It would be much better to have a proper fix though.
Thanks for the quick reply :-) That's we landed on for the short term :+1: Great, thanks for clarifying.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Thanks !
Change:
//! user of the `DepNode` API of having to know how to compute the expected //! fingerprint for a given set of node parameters. <del> use crate::mir; </del> use crate::mir::interpret::{GlobalId, LitToConstInput}; use crate::traits; use crate::traits::query::{

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
// Neither of these generators have the resume arg live across the `yield`, so they should be // 4 Bytes in size (only storing the discriminant) <del> assert_eq!(size_of_val(&gen_copy), 4); assert_eq!(size_of_val(&gen_move), 4); </del> <ins> assert_eq!(size_of_val(&gen_copy), 1); assert_eq!(size_of_val(&gen_move), 1); </ins> }

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
= note: see issue #51911 <https://github.com/rust-lang/rust/issues/51911> for more information = help: add `#![feature(const_raw_ptr_deref)]` to the crate attributes to enable <del> error: aborting due to previous error </del> <ins> error[E0658]: dereferencing raw pointers in constant functions is unstable --> $DIR/E0396.rs:12:11 | LL |     match *INFALLIBLE {} |           ^^^^^^^^^^^ | = note: see issue #51911 <https://github.com/rust-lang/rust/issues/51911> for more information = help: add `#![feature(const_raw_ptr_deref)]` to the crate attributes to enable error[E0658]: dereferencing raw pointers in constants is unstable --> $DIR/E0396.rs:15:36 | LL |     const BAD: () = unsafe { match *INFALLIBLE {} }; |                                    ^^^^^^^^^^^ | = note: see issue #51911 <https://github.com/rust-lang/rust/issues/51911> for more information = help: add `#![feature(const_raw_ptr_deref)]` to the crate attributes to enable error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

Discussion:
The code below compiles as of 1.46, but I'm not sure it should, since it dereferences a raw pointer in a const block, which is only allowed in nightly with the flag:
modify labels to +A-raw-pointers +A-const-fn
cc
Ah, that looks like the const version of the old "uninhabited match" problem... The MIR for is So somehow the deref already vanished, and hence the const analysis cannot catch it. But doesn't unsafety checking also happen on the MIR? Why does that work?
It seems that whenever the dereference is not bound to a variable, it compiles, but whenever bound to a variable, it fails to compile:
I don't believe this is an unsoundness. Unsafe code is required to cause anything here. That's the final MIR, since without this will fail to compile, it must be there for unsafety checking, thus it must also be there for const checking. Not sure why we fail to catch this.
Agreed. This is a case of "oops a nightly-only feature is available on stable", which is bad, but it is not an unsoundness.
Assigning and removing as in the prioritization working group.
The initial MIR looks like this: So probably the issue is that const-checking ignores ?
oh... yea.. we ignored it on purpose... "because it doesn't actually do anything" :upsidedownface: I guess we should visit all places within statements that we otherwise ignore during const-checking?
Well, at least we need to visit . ;)
Do we really? The check is done in , which should be called even for the projection in the place in the fake read.
Oh wait, we don't call unconditionally! That seems like... a problem.^^
Proposed a fix:
Change:
declare_tool_lint! { pub rustc::USAGE_OF_TY_TYKIND, Allow, <del> "usage of `ty::TyKind` outside of the `ty::sty` module" </del> <ins> "usage of `ty::TyKind` outside of the `ty::sty` module", report_in_external_macro: true </ins> } declare_tool_lint! { pub rustc::TY_PASS_BY_REFERENCE, Allow, <del> "passing `Ty` or `TyCtxt` by reference" </del> <ins> "passing `Ty` or `TyCtxt` by reference", report_in_external_macro: true </ins> } declare_tool_lint! { pub rustc::USAGE_OF_QUALIFIED_TY, Allow, <del> "using `ty::{Ty,TyCtxt}` instead of importing it" </del> <ins> "using `ty::{Ty,TyCtxt}` instead of importing it", report_in_external_macro: true </ins> } declare_lint_pass!(TyTyKind => [

Discussion:
Filing this since had the idea and so that we don't forget. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
It should be as easy (unless I'm overlooking something) as adding to all declaretool_lint invocations and then fixing the fallout (changing imports as described by the lint)
I'd like to handle this claim
Change:
<ins> //@ run-rustfix #![allow(unreachable_code, dead_code)] fn main() { fn mismatch_types1() -> i32 { match 1 { x => dbg!(x), //~ ERROR mismatched types } todo!() } fn mismatch_types2() -> i32 { match 2 { x => { dbg!(x) //~ ERROR mismatched types } } todo!() } fn mismatch_types3() -> i32 { match 1 { _ => dbg!(1) //~ ERROR mismatched types } todo!() } fn mismatch_types4() -> i32 { match 1 { _ => {dbg!(1)} //~ ERROR mismatched types } todo!() } } </ins>

Discussion:
when using i even got this suggestion recommending i return DefKind from the GlobalCtxt::enter closure, which isn't even remotely the right type. it also seems to only show up when using macros? all around quite strange. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
compiler.enter(|queries| { let sess = compiler.session(); <ins> if sess.opts.describe_lints { let (_, lint_store) = &*queries.register_plugins()?.peek(); describe_lints(sess, lint_store, true); return Ok(()); } </ins> // We need to hold on to the complete resolver, so we cause everything to be // cloned for the analysis passes to use. Suboptimal, but necessary in the // current architecture.

Discussion:
I tried this code: I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does. Instead, this happened: Rustdoc ignored the flag. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.53.0-nightly ( 2021-04-03) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
option is parsed into , but is then ignored: It should be pretty straightforward to instead call when this flag is set. claim
Make sure you call init_lints first, or it will be missing rustdoc's own lints.
Re adding a test for this... is there any way to have check only for whether some substring appears within stderr? Else every time a lint is /removed, or its level modified, the test will need updating—which seems far too brittle to me?
I mean, personally that seems ok to me as long as you can update it with . But if you think it's a hassle you could use .