jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![deny(broken_intra_doc_links)] pub mod r#impl { pub struct S; impl S { /// See [Self::b]. // @has raw_ident_self/impl/struct.S.html // @has - '//a[@href="../../raw_ident_self/impl/struct.S.html#method.b"]' 'Self::b' pub fn a() {} pub fn b() {} } } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: The link resolves to . Instead, this happened: rustdoc can't resolve the link <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: and <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Maybe I shouldn't have used pretty printing after all ... I'll try reverting and see if it helps.
Assigning and removing as in the prioritization working group.
Change:
impl<T: Clone, A: Allocator + Clone> Clone for IntoIter<T, A> { #[cfg(not(test))] fn clone(&self) -> Self { <del> self.as_slice().to_vec_in(self.alloc.clone()).into_iter() </del> <ins> self.as_slice().to_vec_in(self.alloc.deref().clone()).into_iter() </ins> } #[cfg(test)] fn clone(&self) -> Self { <del> crate::slice::to_vec(self.as_slice(), self.alloc.clone()).into_iter() </del> <ins> crate::slice::to_vec(self.as_slice(), self.alloc.deref().clone()).into_iter() </ins> } }

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'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
} /// Returns an iterator over `chunk_size` elements of the slice at a time. <del> /// The chunks are mutable and do not overlap. If `chunk_size` does </del> <ins> /// The chunks are mutable slices, and do not overlap. If `chunk_size` does </ins> /// not divide the length of the slice, then the last chunk will not /// have length `chunk_size`. ///

Discussion:
I know that it's implied by the , but it wasn't immediately obvious to me that the chunks returned by can (I'm avoiding use of the term "recursive" here) have or called on themselves (). Is there any interest in a PR that makes this explicit? It seems that especially when working with threads and work-stealing, this is something that users want to do.
Is it enough to stress that each chunk is itself a slice (or mutable slice)?
Hm. What would be the distinction between stressing it and showing it? In theory, it should be obvious that because the chunk is a slice, you can call on it. At the same time, it depends on the intended audience; For the beginner, it means that there's no need to go off to the playpen or ask a question (which may or may not be a good thing, depending on your point of view). Either option is an improvement, and I'm probably over-thinking the whole thing now.
In general, API docs usually are written for an intermediate/advanced user: we don't generally mention "oh and because this has a return type of foo you can call these other things on it." Where does this stop and end?
Fair point. But what about explicitly stating that the functions return slices, as opposed to "an iterator"?
It does return an iterator - an iterator over slices.
Undeniably true, but I don't think it's clear; The docs say "an iterator over / elements_ of the slice".
I'm not sure one would be able to use and correctly without understanding that they yield slices. Once you understand that you can use to divide a slice into more slices, surely it makes sense that one can divide those slices in yet more slices, In much the same way that one can add two numbers and use the result for further addition.
Yes we should clarify the docs to say it returns an iterator whose elements are slices.
Change:
<ins> error[E0670]: `async fn` is not permitted in Rust 2015 --> $DIR/drop-location-span-error-rust-2021-incompatible-closure-captures-96258.rs:8:16 | LL |     pub(crate) async fn new( |                ^^^^^ to use `async fn`, switch to Rust 2018 or later | = help: pass `--edition 2021` to `rustc` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error[E0412]: cannot find type `Duration` in this scope --> $DIR/drop-location-span-error-rust-2021-incompatible-closure-captures-96258.rs:10:19 | LL |         interval: Duration, |                   ^^^^^^^^ not found in this scope | help: consider importing this struct | LL | use std::time::Duration; | error: aborting due to 2 previous errors Some errors have detailed explanations: E0412, E0670. For more information about an error, try `rustc --explain E0412`. </ins>

Discussion:
Works even with calling just - no need for a project, and does not need as a dependency in . Bug exists on 1.59, 1.60, beta and nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Do you have a codebase that can be shared instead? Unfortunately, it's kinda difficult to investigate this without seeing what triggered the ICE.
might be a duplicate of
I tried my hands at minimizing this, and it turned out way easier than I thought. Updated the original comment with reproduction code.
I subscribed to this thread for curiosity about ICEs on . Here's a smaller crashing program using
Managed to minimize it more:
you might be right, especially after I narrowed down the reproduction code.

<!-- 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. --code reduced from <!-- 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
another example: `
Change:
#[cfg(test)] mod test { use super::*; <del> use io::net::ip::{Ipv4Addr, SocketAddr}; </del> <ins> use io::net::ip::{SocketAddr}; </ins> use io::*; <del> use io::test::*; </del> use prelude::*; iotest!(fn bind_error() {

Discussion:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

We should add some sort of special comment like . Here is the hashcode of the current snapshot. The build system can then issue warnings if such a comment exists and is not still the current snapshot.
do you still feel that this would be useful?
Still seems useful to me.
Still very useful.
(bug triage) This would be nice, but is not a blocker.
Change:
T=$(command -v $P 2>&1) if [ $? -eq 0 ] then <del> VER0=$($P --version 2>/dev/null | head -1  |  sed -e 's/[^0-9]*([vV]?[0-9.]+[^ ]*).*/1/' ) </del> <ins> VER0=$($P --version 2>/dev/null  |  grep -o '[vV]?[0-9][0-9.][a-z0-9.-]*' | head -1 ) </ins> if [ $? -eq 0 -a "x${VER0}" != "x" ] then VER="($VER0)"

Discussion:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.
Change:
//! Print diagnostics to explain why values are borrowed. <del> use std::collections::VecDeque; use rustc_data_structures::fx::FxHashSet; </del> use rustc_errors::{Applicability, Diagnostic}; use rustc_index::vec::IndexVec; use rustc_infer::infer::NllRegionVariableOrigin;

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this:
Change:
if !custom_llvm_used && target_data_layout != llvm_data_layout { bug!( <del> "data-layout for builtin `{}` target, `{}`,  differs from LLVM default, `{}`", sess.target.llvm_target, target_data_layout, llvm_data_layout </del> <ins> "data-layout for target `{rustc_target}`, `{rustc_layout}`,  differs from LLVM target's `{llvm_target}` default layout, `{llvm_layout}`", rustc_target = sess.opts.target_triple, rustc_layout = target_data_layout, llvm_target = sess.target.llvm_target, llvm_layout = llvm_data_layout </ins> ); } }

Discussion:
I'm new to Rust and I try to compile a project with a (I'm also new to that project and that project is not well organized.) when I use Makefile to make, the process of making executes and it reports it's a bug, so I'm here. I'm fresh here so if there is some information I don't provide, please tell me and I will try my best to provide it. Thank you! <!-- 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. --here I couldn't provide the example code since I don't really know the minimal set of code to be compiled the source code of the repo is in rustc should be in the nightly mode rust code is in the rust/sel4-rust/ in directory will execute in directory <!-- 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
Thank you for filing an issue! When I click that linked you posted, I get an error. Is it set that other people can view it?
Sorry, I have fixed the typo. Now the link should be right.(next time I will be more careful to check my issue)
The root of the issue is in the target definition file that the repository contains, however there are three other bugs that can be fixed in rustc: should not ICE when invalid external targets are being used; should report the actual target name/file in the error message, not the LLVM target name; target files are allowed to set the property.
The minimal target file to reproduce: with
( is a 404 )
Change:
<del> Subproject commit 6145fe6bac65c38375f1216a565a6cc7deb89a2d </del> <ins> Subproject commit ddf1b89b861d297c6ef3f09b70d853e81ccc85ff </ins>

Discussion:
I tried this code: running I expected to see this happen: Nothing Instead, this happened: wine: Unhandled page fault on read access to 726F735F at address 7AADD340 (thread 0734), starting debugger... Running with using the 64bit target, no crash happens, as expected. :
Would be helpful to get a backtrace of the crash. maybe you have ideas
Of course! This is what windbg gave me: Please note that I got a crash from a different wine version (sorry, can't recall which one) as well.
The current Wine stable version is 9.0. Please try the latest stable Wine.
Also, it's not clear from your report that you actually have full 32-bit Windows support installed. It is not enough to simply have Wine installed to get that. You have to have a fully and correctly configured multilib setup. . Do other_ 32-bit Windows applications run on the system in question and successfully perform crash reporting with dbghelp?
Yes, I have a good setup - I run a lot of 32-bit applications (mostly Starcraft 1.16.1 and 32-bit applications connecting to it). Here is an updated "program": This was with the same wine version, now let's retry with wine 9.0. I replaced the println with backtrace again: And the backtrace from winedbg: I will do another one with wine-devel 9.3.
I omitted the backtrace, its basically the same.
Aha, thanks for the followup info! We think we have a fix for this en route.
Change:
if let Some(def_id) = def_id && self.infcx.tcx.def_kind(def_id).is_fn_like() && let Some(pos) = args.iter().position(|arg| arg.hir_id == expr.hir_id) <del> && let ty::Param(_) = self.infcx.tcx.fn_sig(def_id).skip_binder().skip_binder().inputs() [pos + offset] .kind() </del> <ins> && let Some(arg) = self .infcx .tcx .fn_sig(def_id) .skip_binder() .skip_binder() .inputs() .get(pos + offset) && let ty::Param(_) = arg.kind() </ins> { let place = &self.move_data.move_paths[mpi].place; let ty = place.ty(self.body, self.infcx.tcx).ty;

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 5'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 5'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
bisects to cc
Thank you. claim
Change:
LL | const C = 42; |       ^ help: provide a type for the item: `C: i32` <ins> error: missing type for `const` item --> $DIR/const-no-type.rs:38:7 | LL | const D = &&42; |       ^ help: provide a type for the item: `D: &&i32` </ins> error: missing type for `static` item <del> --> $DIR/const-no-type.rs:38:8 </del> <ins> --> $DIR/const-no-type.rs:43:8 </ins> | LL | static S = Vec::<String>::new(); |        ^ help: provide a type for the item: `S: std::vec::Vec<std::string::String>` error: missing type for `static mut` item <del> --> $DIR/const-no-type.rs:43:12 </del> <ins> --> $DIR/const-no-type.rs:48:12 </ins> | LL | static mut SM = "abc"; |            ^^ help: provide a type for the item: `SM: &str`

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit:
This is presumably due to -- cc
This was . Tagging it as . Not removing nomination until we can assign this issue.
assign (assigning based on claim that this was injected by PR )
This is the feature where for a with a missing type will look at the body and get the type from there. We should replace all regions in that situation with , just so the code which ICEs here will continue to ICE for legitimate bugs.
Doesn't reproduce with ( ):
Hmmmm, I'm not sure I agree with that assessment, unless -- well -- I guess you're saying that the "correct static type" for any such expression would be anyway?
yes, this is recovery for a guaranteed error, after all. A slightly more aggressive example: Results in this query stack for the ICE: I have no idea why changing to changes anything but they should both ICE IMO (before we switch to replacing erased regions with ). I'm now worried there are other places in which is used to extract some type and "export" it outside of the context of the body, without the necessary precautions.
Change:
} mir::Rvalue::Len(ref lvalue) => { <del> let tr_lvalue = self.trans_lvalue(&bcx, lvalue); </del> <ins> let size = self.evaluate_array_len(&bcx, lvalue); </ins> let operand = OperandRef { <del> val: OperandValue::Immediate(tr_lvalue.len(bcx.ccx)), </del> <ins> val: OperandValue::Immediate(size), </ins> ty: bcx.tcx().types.usize, }; (bcx, operand)

Discussion:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .
Change:
_ => return false, } <del> let impl_predicates = tcx.predicates_of(impl_def_id).instantiate(tcx, impl_args); ocx.register_obligations(impl_predicates.predicates.iter().map(|&predicate| { Obligation::new(tcx, ObligationCause::dummy(), param_env, predicate) })); </del> <ins> let obligations = tcx .predicates_of(impl_def_id) .instantiate(tcx, impl_args) .into_iter() .map(|(predicate, _)| { Obligation::new(tcx, ObligationCause::dummy(), param_env, predicate) }) // Kinda hacky, but let's just throw away obligations that overflow. // This may reduce the accuracy of this check (if the obligation guides // inference or it actually resulted in error after others are processed) // ... but this is diagnostics code. .filter(|obligation| { infcx.next_trait_solver() || infcx.evaluate_obligation(obligation).is_ok() }); ocx.register_obligations(obligations); </ins> ocx.select_where_possible().is_empty() })

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 have a full repro in , but the short version is, it seems like some cases of code that look_ like an omitted type should be inferrable: while certain dependencies, leading to , are in the compile pathway (I could only get it to reproduce via a weird dependency chain via a workspace and a couple of public crates), can lead to an overflow: If the dependency chain is altered in any way that I could divine, the expected error is output: <!-- 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. --I've reproduced this bug both in and in . :
Bisects to nightly-2023-10-07. In nightly-2023-10-06, we get "the expected error" shown above.
Looks like , because reproduces the issue, but the previous commit on master () does not.
Minimal:
I'll put up a fix in a sec
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> error: generic parameters may not be used in const operations --> $DIR/issue-67945-4.rs:10:27 | LL |         let x: Option<Box<S>> = None; |                           ^ cannot perform const operation using `S` | = note: type parameters may not be used in const expressions = help: use `#![feature(generic_const_exprs)]` to allow generic const expressions error[E0392]: parameter `S` is never used --> $DIR/issue-67945-4.rs:8:12 | LL | struct Bug<S> { |            ^ unused parameter | = help: consider removing `S`, referring to it in a field, or using a marker such as `PhantomData` = help: if you intended `S` to be a const parameter, use `const S: usize` instead error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0392`. </ins>

Discussion:
The following ICE's on nightly and beta: <details<summaryBacktrace:</summary</details
Reduced: ICE most likely occurs in: I cannot seem to reproduce this without an , so cc
Reduced even more: (Please include all 3 variants thus far in a regression test.)
I looked into this briefly and found that on this line: has the value: Digging a bit deeper, the generics appear to be empty because of the following lines: I can confirm that adding makes this code compile, so I suspect that this is blocked on .
What would be the consequences of always returning the DefId?
It causes query cycle errors at the moment.
Discussed at T-compiler meeting. Due to all the known examples being compile-time errors, the ICE here does not seem so strong a hazard as to warrant weekly visits during triage. (Certainly failing more gracefully would be great. But its not something we're going to e.g. block a release on.) Downgrading priority to P-medium.
Some relevant examples. This gives an (incorrect) error on stable that does not hold: This ICEs on stable:
Is there a reason why we can't just disallow type parameters from appearing within constants during resolve, like we do for type parameters from outer functions? Obviously const generics/lazy normization willl loosen this rule.
good point, I imagine that might work.
Another variant on this bug:
Triage: The two examples that Centril posted ( and ) are no longer ICEs in the latest nightly. Possibly related to ?
Maybe we should just add tests then?
Sounds good! I'll do later.
Another variant (though likely the same): This gives a different to the original, despite being essentially the same code.
Triage: All the snippets including the original are no longer ICE with the latest nightly:
Change:
} fn error_item_without_body(&self, sp: Span, ctx: &str, msg: &str, sugg: &str) { <ins> let source_map = self.session.source_map(); let end = source_map.end_point(sp); let replace_span = if source_map.span_to_snippet(end).map(|s| s == ";").unwrap_or(false) { end } else { sp.shrink_to_hi() }; </ins> self.err_handler() .struct_span_err(sp, msg) .span_suggestion( <del> self.session.source_map().end_point(sp), </del> <ins> replace_span, </ins> &format!("provide a definition for the {}", ctx), sugg.to_string(), Applicability::HasPlaceholders,

Discussion:
It suggests when it should suggest or at least suggest () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably the "free function without body" variant has this bug as well.
The code at issue:
I think I'll take a shot at this. claim
That was... an easy fix. to That provides this: which isn't entirely satisfactory imo cause the suggestion span is directly after the rather than a space after, but it's at least valid Rust code that can be formatted into more "properly" formatted Rust code.
It appears that it has a similar bug: Looks like this can probably be fixed similarly.
Oh wait, that bug was caused by me. It looks like I'll probably have to implement a better solution.
Okay, so it appears that this bug is triggered in inherent impls with and without a semicolon, and in free functions with a semicolon. I'll have to find some kind of way to change the span depending on if it had a semicolon or not.
Okay, so it looks like in 99% of cases that trigger the same code path as this error: free fn free const free static free type inherent const inherent fn trait const trait type trait fn the existing code is already correct, as in those cases a semicolon is (usually) required. Either we can modify the parser to give some kind of indication to the AST validator that an inherent fn/const/type has no semicolon at the end, or we can just use a hack to check if there's a semicolon at the end of the span
I'm not quite sure how this should be fixed :/
I would suggest asking in since someone there can probably give advice.