jiebi/CodeConvo huggingface dataset:
Code change:
#[inline] fn next(&mut self) -> Option<T> { <del> self.iter.next().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } let tail = self.tail; self.tail = wrap_index(self.tail.wrapping_add(1), self.ring.len()); // Safety: // - `self.tail` in a ring buffer is always a valid index. // - `self.head` and `self.tail` equality is checked above. unsafe { Some(ptr::read(self.ring.as_ptr().get_unchecked_mut(tail))) } </ins> } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> self.iter.size_hint() </del> <ins> let len = count(self.tail, self.head, self.ring.len()); (len, Some(len)) </ins> } }

Related discussion:
text: liballoc's fails when run in Miri. The error occurs in the call: is called with a as argument. contains contains a shared reference to a slice; that slice is thus marked as "must not be mutated for the entire duration of this function call". calls calls calls calls , which eventually drops the . calls to re-arrange stuff (I have not fully understood this yet), and in some cases this will end up writing to memory that the slice in points to. I am not sure what the best way to fix this is. We have to fix holding (indirectly) a shared reference to something that it'll mutate during its . The mutation is likely there for a reason, so I guess the shared reference has to go. (FWIW, this shared reference already caused other trouble, but that was fixed by ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah I guess just change it to and toss in a PhantomData for the borrow. shrug
You mean, change this in as well? Sure, that should work. In principle this reduces the precision of compiler analyses on .
ahh misread. maybe would just not use Iter then. depends on what the impl looks like now
But the first thing it does is which should exhaust the such that its is an empty slice. I suppose its pointer will still be somewhere in the deque's memory, but with length 0 it can't actually read anything. Is that not good enough to appease Miri?
No. This code still matches the pattern There is no notion of "exhausting" or "consuming" a shared reference. When you create a shared reference with a certain lifetime, you promise that until that lifetime ends, no mutation happens. here is mutable so you can change what the slice points to, but that has no effect at all on the guarantees that have been made about the value that was initially passed to . Now, lifetimes are an entirely static concept, so for Stacked Borrows a "lifetime" generally is "until the pointer is used for the last time".
Code change:
#[inline] fn next(&mut self) -> Option<T> { <del> self.iter.next().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } let tail = self.tail; self.tail = wrap_index(self.tail.wrapping_add(1), self.ring.len()); // Safety: // - `self.tail` in a ring buffer is always a valid index. // - `self.head` and `self.tail` equality is checked above. unsafe { Some(ptr::read(self.ring.as_ptr().get_unchecked_mut(tail))) } </ins> } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> self.iter.size_hint() </del> <ins> let len = count(self.tail, self.head, self.ring.len()); (len, Some(len)) </ins> } }

Related discussion:
text: However, for the special case of a reference being passed to a function, Stacked Borrows asserts that the "lifetime" will last at least as long as the function the reference is pointed to. (This is enforced by the "barriers" explained .) This is extremely useful for optimizations.
forward to . I wouldn't want to copy those.
Oh, I also didn't realize that doesn't actually shrink down to an empty slice -- it only updates its indexes. It would otherwise have to use two slices for the wrapped head and tail. So that full shared reference does still exist after the iterator is exhausted. (This also raises the validity question of having references to uninitialized data.) Could we base on instead? We could arrange to work through that mutable reference too, so there's no question of mutable aliasing.
That might work. However, must not access in that case -- that would be in conflict with the unique reference in .
Hmm, does need to be covariant over ? I guess would break that.
Actually this idea of "consuming a shared ref" is far from unique to ... the following code also errors in Miri:
As I understand it, Miri and stacked borrows should be "more powerful" than the Rust borrow checker, right? So, is this an example where Miri does not match what Rust allows or is this a bug in Rust that could lead to undefined behaviour in safe code? ()
-- I believe is admitting that example as something that should be allowed. But this issue with involves raw pointers, which rustc doesn't check at all, so miri is in uncharted waters here.
This is up for us all to decide. I can't tell you. ;) Not necessary. I have argued that / are problematic long before Stacked Borrows. The lifetimes there are, strictly speaking, wrong. I think it would be reasonable to rule that they have to use raw pointers.
FWIW here is a stand-alone version of the testcase to reproduce this with Miri (but it needs access to some private internals):
See for the issue about whether Stacked Borrows should allow such code or not. For now, with , Miri accepts this code again. So I am going to close the issue here. It still represents an interesting data point to inform what Stacked Borrows rules should be.
Code change:
#[inline] fn next(&mut self) -> Option<T> { <del> self.iter.next().map(|elt| unsafe { ptr::read(elt) }) </del> <ins> if self.tail == self.head { return None; } let tail = self.tail; self.tail = wrap_index(self.tail.wrapping_add(1), self.ring.len()); // Safety: // - `self.tail` in a ring buffer is always a valid index. // - `self.head` and `self.tail` equality is checked above. unsafe { Some(ptr::read(self.ring.as_ptr().get_unchecked_mut(tail))) } </ins> } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> self.iter.size_hint() </del> <ins> let len = count(self.tail, self.head, self.ring.len()); (len, Some(len)) </ins> } }

Related discussion:
text: nods wisely just gotta stand still long enough for the spec to bend around you
;-) I don't think the decision is made either way, but for now with several counterexamples in libstd, it is not helpful for Miri to complain about this. Plus, this matches what we formalized in Coq; the basic optimizations that we considered so far are all fine with this change.
See there actually is a bug here right now, because we do emit for passed to a function. So what Miri found is actually UB in the LLVM IR that we are generating right now. Reopening for now, but maybe it makes more sense to treat this as a duplicate of
Smaller reproduction that I found in (a now closed dupe of this issue) that doesn't rely on VecDeque internals, that fails now with
re-enables the part of Stacked Borrows that got disabled (in parts) to work around the issue, before I knew that we actually have here and are risking real miscompilations.
claim
Code change:
fn build_external_function(cx: &DocContext, did: DefId) -> clean::Function { let sig = cx.tcx.fn_sig(did); <del> let constness = if cx.tcx.is_const_fn(did) { </del> <ins> let constness = if cx.tcx.is_min_const_fn(did) { </ins> hir::Constness::Const } else { hir::Constness::NotConst

Related discussion:
text: Regression from 1.26.0 to 1.27.0 and later. See for example See also and
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. const X: &'static str = "12345"; fn test(s: String) -> bool { match s.as_slice() { X => true, _ => false } } fn main() { assert!(test("12345".to_string())); } </ins>

Related discussion:
text: On the latest nightly (previously it worked fine) Rust fails to compile this code: It emits this error message: I managed to strip it down to this example: It fails to compile with this error: If is replaced with , then it compiles fine, so the error seems to be related to matching on s.
Sorry for the breakage, fix on its way.
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. const X: &'static str = "12345"; fn test(s: String) -> bool { match s.as_slice() { X => true, _ => false } } fn main() { assert!(test("12345".to_string())); } </ins>

Related discussion:
text: I just upgraded my to . But when I tried to rebuild my project, it failed with the following errors: , , etc... are constants of type . What does the error mean? I am confused.
Thanks . It seems that the bug is fixed, please merge it to upstream asap. :)
The same as
Code change:
Some(f) => f, None => return DummyResult::any(sp) }; <del> let file = cx.resolve_path(file, sp); </del> <ins> let file = match cx.resolve_path(file, sp) { Ok(f) => f, Err(mut err) => { err.emit(); return DummyResult::any(sp); }, }; </ins> match cx.source_map().load_binary_file(&file) { Ok(bytes) => match std::str::from_utf8(&bytes) { Ok(src) => {

Related discussion:
text: to reproduce the fault this can be used: will result in this ICE: thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', note: Run with RUSTBACKTRACE=1 environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.36.0 ( 2019-07-03) running on x86_64-unknown-linux-gnu the question is what is the path that shall be used when the code is from stdin maybe some temp file name in the currrent working dir.
This ICE also occurs when using and , which makes sense as they use the same mechanism under the hood (, , meaning it also .
While poking at this I also noticed that items are silently ignored, and filed .
Code change:
#[diag(lint_range_endpoint_out_of_range)] pub struct RangeEndpointOutOfRange<'a> { pub ty: &'a str, <del> #[suggestion(code = "{start}..={literal}{suffix}", applicability = "machine-applicable")] pub suggestion: Span, pub start: String, pub literal: u128, pub suffix: &'a str, </del> <ins> #[subdiagnostic] pub sub: UseInclusiveRange<'a>, } #[derive(Subdiagnostic)] pub enum UseInclusiveRange<'a> { #[suggestion( lint_range_use_inclusive_range, code = "{start}..={literal}{suffix}", applicability = "machine-applicable" )] WithoutParen { #[primary_span] sugg: Span, start: String, literal: u128, suffix: &'a str, }, #[multipart_suggestion(lint_range_use_inclusive_range, applicability = "machine-applicable")] WithParen { #[suggestion_part(code = "=")] eq_sugg: Span, #[suggestion_part(code = "{literal}{suffix}")] lit_sugg: Span, literal: u128, suffix: &'a str, }, </ins> } #[derive(LintDiagnostic)]

Related discussion:
text: <!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim
Code change:
use rustc_hir as hir; use rustc_middle::mir::visit::MutVisitor; use rustc_middle::mir::{self, dump_mir, MirPass}; <del> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_target::abi::FieldIdx; pub struct ByMoveBody;

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )
Code change:
use rustc_hir as hir; use rustc_middle::mir::visit::MutVisitor; use rustc_middle::mir::{self, dump_mir, MirPass}; <del> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, InstanceDef, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_target::abi::FieldIdx; pub struct ByMoveBody;

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
Code change:
// Parse: `for <src_pat> in <src_expr> <src_loop_block>` let pat = self.parse_pat()?; <del> self.expect_keyword(keywords::In)?; </del> <ins> if !self.eat_keyword(keywords::In) { let in_span = self.prev_span.between(self.span); let mut err = self.sess.span_diagnostic .struct_span_err(in_span, "missing `in` in `for` loop"); err.span_suggestion_short(in_span, "try adding `in` here", " in ".into()); err.emit(); } </ins> let expr = self.parse_expr_res(Restrictions::NO_STRUCT_LITERAL, None)?; let (iattrs, loop_block) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs);

Related discussion:
text: Hello, with rustc 1.17.0-nightly ( 2017-03-22), the following code gives this error message: An improved error message could add a hint :
Current output: 1) How would you want to improve upon this? Adding a suggestion? 2) To do so, we could use the same strategy as in : in , try to continue building the expression as if the keyword had been found. If we find further errors, we revert the state of the compiler to right after trying to continue and return the error from . Otherwise we cancel that one and create a new custom diagnostic: 3) or just modify the existing error with the proposed (so it looks like the 2 above). []:
Looks like current output already is an improvement over the reported one, but eithwr 2 or 3 would make it even more obvious i guess. No strong opinions here
Seems to me that the third error is the most clear ("error: missing in loop"); I suspect people using fancy pattern features will figure out what's going on.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

Related discussion:
text: I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

Related discussion:
text: produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

Related discussion:
text: <!-- 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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>

Related discussion:
text: <!-- 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
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":
Code change:
<ins> // check-pass //! [my_module] //~^ WARN public documentation for `private_from_crate_level` links to private item `my_module` mod my_module {} </ins>

Related discussion:
text: It should say instead.
Relevant code: I think the fix is to use the crate name instead of .
Also, I would be curious to see if you can remove altogether by using : That might break renamed modules maybe? I don't remember how modules interact with re-exports.
Code change:
} } <ins> // This stripper discards all private import statements (`use`, `extern crate`) struct ImportStripper; impl fold::DocFolder for ImportStripper { fn fold_item(&mut self, i: Item) -> Option<Item> { match i.inner { clean::ExternCrateItem(..) | clean::ImportItem(..) if i.visibility != Some(hir::Public) => None, _ => self.fold_item_recur(i) } } } pub fn strip_priv_imports(krate: clean::Crate)  -> plugins::PluginResult { (ImportStripper.fold_crate(krate), None) } </ins> pub fn unindent_comments(krate: clean::Crate) -> plugins::PluginResult { struct CommentCleaner;

Related discussion:
text: Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?
Code change:
// except according to those terms. use std::fmt::self; //~ ERROR E0429 <del> //~^ ERROR E0432 </del> fn main () { }

Related discussion:
text: It currently gives two - one for outside and one for an unknown import. The latter should be silenced. e.g.,
I will work on this
On an related note, shouldn't there be a lint for . Maybe say "you can just use ."