jiebi/CodeConvo huggingface dataset:
Change:
//! Common iterator adapters include [`map`], [`take`], and [`filter`]. //! For more, see their documentation. //! <ins> //! If an iterator adapter panics, the iterator will be in an unspecified (but //! memory safe) state.  This state is also not guaranteed to stay the same //! across versions of Rust, so you should avoid relying on the exact values //! returned by an iterator which panicked. //! </ins> //! [`map`]: trait.Iterator.html#method.map //! [`take`]: trait.Iterator.html#method.take //! [`filter`]: trait.Iterator.html#method.filter

Discussion:
What state(s) are iterator adapters allowed to be in after a panic, Obviously they need to memory safe, but how many items are they expected to have consumed? Is it even allowed to call on an (un-fused) iterator after you called, say, on it with a closure that panicked? Asking because this has just come up in two PRs:
I think I personally see this as an edge case a bit like leaking and the like. We definitely need to avoid allowing memory unsafety, but otherwise I think it's reasonable for the iterator to be in an unspecified state. could continue to return values, it could return None, etc. In particular, I'd be fine with this behavior changing over time based on how we adjust the iterator's internal implementation.
I personally feel the same way as I don't think we need to hold ourselves to any particular standard in the standard library other then "stay memory safe"
I agree. I would like for this to be called out briefly in the std::iter module doc, which currently does not mention panic.
Change:
<ins> // Copyright 2015 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. extern crate libc; fn main() { let foo: *mut libc::c_void; let cb: &mut Fn() = unsafe { &mut *(foo as *mut Fn()) //~^ ERROR use of possibly uninitialized variable: `foo` }; } </ins>

Discussion:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!
Change:
"rand 0.7.0", "rustc-workspace-hack", "rustc_version", <ins> "serde", </ins> "shell-escape", "vergen", ]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
<ins> -include ../tools.mk # Test that previously triggered a linker failure with root cause # similar to one found in the issue #69368. # # The crate that provides oom lang item is missing some other lang # items. Necessary to prevent the use of start-group / end-group. # # The weak lang items are defined in a separate compilation units, # so that linker could omit them if not used. # # The crates that need those weak lang items are dependencies of # crates that provide them. all: $(RUSTC) a.rs $(RUSTC) b.rs $(RUSTC) c.rs </ins>

Discussion:
Compiling following under some circumstances result in undefined references to : This linking issue occurs only under for some codegen partitioning but not the others. Reproducing it requires controlling the options that influence the number of codegen units. I can reproduce it with either , or combined with . The weak lang items introduce cyclic dependencies between crates. For example, the alloc crate depends on oom lang item which is defined in std. When linking the std comes first, and it may so happen that object file that contains definition is not used and omitted (this suggest why large number of codegen units is necessary to reproduce the issue), and subsequently alloc crate will fail to link. The [linking code][0] tries to account for cyclic dependencies using start-group and end-group, but as far as I can see it based on assumption that weak lang items dependencies are always reversed, which no longer holds true. [0]:
Change:
"serde_derive", "serde_json", "tempfile", <del> "tester", </del> "winapi 0.3.6", ]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I suspect miri just needs a compiletest update cc
triage: P-medium. Removing nomination label.
So, the compiletest-update was semver-breaking?
The failure seems to be a panic in cargo...?
not quite, nightly rustc broke compiletest and we play catch up with that since the nightly feature is "current nightly" the cargo panic you're seeing is an osx bug in cargo that got fixed
Is this a recent bug? It looks (in Miri CI) as if the bug occurred with stable cargo.
this bug appeared in nightly and got fixed on the next day. Could you cargo version from CI (after installing master toolchain)?
It's recent, but not on stable, maybe you're seeing something else.
FWIW, the trouble was that Travis on the auto branch used a beta cargo, not a stable one, due to caching.
Change:
} #[test] <ins> fn test_bytes_set_memory() { use std::slice::bytes::MutableByteVector; let mut values = [1,2,3,4,5]; values[0..5].set_memory(0xAB); assert!(values == [0xAB, 0xAB, 0xAB, 0xAB, 0xAB]); values[2..4].set_memory(0xFF); assert!(values == [0xAB, 0xAB, 0xFF, 0xFF, 0xAB]); } #[test] </ins> #[should_panic] fn test_overflow_does_not_cause_segfault() { let mut v = vec![];

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .
Change:
<ins> error[E0597]: `v` does not live long enough --> $DIR/dropck-union.rs:49:18 | LL |     v.0.set(Some(&v)); //~ ERROR: `v` does not live long enough |                  ^^ borrowed value does not live long enough LL | } | - | | | `v` dropped here while still borrowed | borrow later used here, when `v` is dropped | = note: values in a scope are dropped in the opposite order they are defined error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
So it turns out that is a problem: The following code should be rejected by dropck, but . This is a nightly-only (because implementing for unions is unstable) soundness issue. I need unsafe code to exploit it, but above should be a perfectly safe to use type.
regression.
Not without guarantees on union validity :) Remember how third parties can legally write garbage into that's not a valid ? This means neither deref nor drop are safe operation in that interpretation.
No, that's not at all what I was saying. We were discussing basic layout invariants. These are invariants the compiler knows about and exploits for enum layout optimizations; violating them is insta-UB. For example, a reference must be non-NULL and aligned. Even a reference being valid is already not covered here as it cannot expressed in terms of just its bit pattern. However, for private fields, types may have arbitrary additional invariants. I hope we agree that the layout invariant for is simple: Just looking at the type , the only layout invariants we have is that none of the fields can be undef and that the first field must not be NULL. Still, a third party cannot legally write any garbage conforming with these invariants into those fields, like setting to ! Doing this is not insta-UB, but can easily lead to UB on the next call to . This is an example for an extra invariant that the compiler does not know about, that the data structure upholds through privacy and that unsafe code in this module can hence rely on. works the same way, its only field is private for this very reason.
Answered in to avoid offtopic here.
Change:
= help: consider using `expect()` to provide a better panic message error: called `.get().unwrap()` on a slice <del> --> tests/ui/get_unwrap.rs:77:24 </del> <ins> --> tests/ui/get_unwrap.rs:78:24 </ins> | LL |         let _x: &i32 = f.get(1 + 2).unwrap(); |                        ^^^^^^^^^^^^^^^^^^^^^

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:
} fn print_type(mut self, ty: Ty<'tcx>) -> Result<Self::Type, Self::Error> { <del> if self.tcx.sess.type_length_limit().value_within_limit(self.printed_type_count) { </del> <ins> let type_length_limit = self.tcx.sess.type_length_limit(); if type_length_limit.value_within_limit(self.printed_type_count) { </ins> self.printed_type_count += 1; self.pretty_print_type(ty) } else {

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: program either compiled successful or compiler generate an error Instead, this happened: rustc eats 100% CPU for several minutes, but nothing generated. I compile this code using both and before I began to write this issue, but compiler do not compile even after this issue is submitted. <!-- 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<summaryBacktrace</summary<p</p</details
Slightly smaller:
Actually, I am very curious that, why rustc do not reach the recursion limit.
Oh sorry, you're right, it does hit the recursion limit if I let it run long enough (about 10 seconds).
Here's a proper minimization:
Partial backtrace of the hang: <details</details
So it actually hangs while trying to print the overflow error :laughing:
Bisected:
looks suspicious.
hang but generate a failed massage:
Assigning and removing .
Change:
<ins> #![feature(unsize, dispatch_from_dyn)] use std::marker::Unsize; use std::ops::DispatchFromDyn; #[allow(unused)] struct Foo<'a, T: ?Sized> { _inner: &'a &'a T, } impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {} //~^ ERROR the trait bound `&'a T: std::marker::Unsize<&'a U>` is not satisfied //~| NOTE the trait `std::marker::Unsize<&'a U>` is not implemented for `&'a T` //~| NOTE all implementations of `Unsize` are provided automatically by the compiler //~| NOTE required because of the requirements on the impl fn main() {} </ins>

Discussion:
I was playing with while I encountered a The simplest example I have producing the bug is Here is . It works if I remove the struct and put the directly in . The complete backtrace is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimised ()
claim
Change:
span = mir.span; let layout = ecx.layout_of(mir.return_ty().subst(tcx, cid.instance.substs))?; let alloc = tcx.interpret_interner.get_cached(cid.instance.def_id()); <ins> let is_static = tcx.is_static(cid.instance.def_id()).is_some(); </ins> let alloc = match alloc { Some(alloc) => { assert!(cid.promoted.is_none());

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
error: aborting due to 5 previous errors <ins> For more information about this error, try `rustc --explain E0704`. </ins>

Discussion:
Environment: rustc 1.31.0-nightly ( 2018-10-25) and rustc 1.30.0 ( 2018-10-24) Rustc produces E0704 error code on the following (syntactically wrong) code: But but neither nor is aware of this error
I can pick this up unless you'd want to do it yourself! This will be the first the I am writing docs for errors (unless Undin wants to do it of course). I guess the general structure looks a bit like this?: Short description of the error Example of bad syntax Example of good syntax Or should there be something else I can add?
Unfortunately, at this moment I don't have enough time to fix it myself so I will be glad if you fix it
I will try my best this week! Hopefully I'll be able to create a PR on Wednesday. I'll tag you once it's done :)
Change:
} } <del> fn def_id(self, tcx: TyCtxt<'_>) -> DefId { </del> <ins> fn def_id(self, tcx: TyCtxt<'_>) -> Option<DefId> { </ins> match self { <del> Res::Def(_, id) => id, Res::Primitive(prim) => *PrimitiveType::primitive_locations(tcx).get(&prim).unwrap(), </del> <ins> Res::Def(_, id) => Some(id), Res::Primitive(prim) => PrimitiveType::primitive_locations(tcx).get(&prim).copied(), </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
cc
Rustdoc assumes that there is always a module for every primitive type referred to by a doc link, which is not the case in the code example above or any "minimal core" example not containing the primitive documentation modules.
Fixed in
Change:
<ins> fn foo<F: FnMut()>() { let _: Box<F> = Box::new(|| ()); //~^ ERROR mismatched types } fn main() {} </ins>

Discussion:
Minimal example: The error is technically correct. I specified, that I want a box of F, but I create a closure. Because F is generic, it is caller-chosen and I create a new closure, which has a different type. Still, it took me quite some time to find out what was going on in the more complicated real code. I think that it would help to add a note here explaining, that each closure has a different type, and that the inner closure does not match the type F exactly. Maybe additionally a hint could be , stating to use instead (i.e. the traits F is bound to).
Current output: It doesn't handle the closure case in any special way, and it should.
I’m experiencing the same problem
Change:
fn new(cgcx: &'a CodegenContext, handler: &'a Handler, llcx: ContextRef) -> DiagnosticHandlers<'a> { <del> let data = Box::new((cgcx, handler)); </del> <ins> let data = Box::into_raw(Box::new((cgcx, handler))); </ins> unsafe { <del> let arg = &*data as &(_, _) as *const _ as *mut _; llvm::LLVMRustSetInlineAsmDiagnosticHandler(llcx, inline_asm_handler, arg); llvm::LLVMContextSetDiagnosticHandler(llcx, diagnostic_handler, arg); } DiagnosticHandlers { inner: data, llcx: llcx, </del> <ins> llvm::LLVMRustSetInlineAsmDiagnosticHandler(llcx, inline_asm_handler, data as *mut _); llvm::LLVMContextSetDiagnosticHandler(llcx, diagnostic_handler, data as *mut _); </ins> } <ins> DiagnosticHandlers { data, llcx } </ins> } } impl<'a> Drop for DiagnosticHandlers<'a> { fn drop(&mut self) { <ins> use std::ptr::null_mut; </ins> unsafe { <del> llvm::LLVMRustSetInlineAsmDiagnosticHandler(self.llcx, inline_asm_handler, 0 as *mut _); llvm::LLVMContextSetDiagnosticHandler(self.llcx, diagnostic_handler, 0 as *mut _); </del> <ins> llvm::LLVMRustSetInlineAsmDiagnosticHandler(self.llcx, inline_asm_handler, null_mut()); llvm::LLVMContextSetDiagnosticHandler(self.llcx, diagnostic_handler, null_mut()); drop(Box::from_raw(self.data)); </ins> } } }

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
) { let member_constraints = self.member_constraints.clone(); for m_c_i in member_constraints.all_indices() { <del> debug!("check_member_constraint(m_c_i={:?})", m_c_i); </del> <ins> debug!(?m_c_i); </ins> let m_c = &member_constraints[m_c_i]; let member_region_vid = m_c.member_region_vid; debug!( <del> "check_member_constraint: member_region_vid={:?} with value {}", member_region_vid, self.region_value_str(member_region_vid), </del> <ins> ?member_region_vid, value = ?self.region_value_str(member_region_vid), </ins> ); let choice_regions = member_constraints.choice_regions(m_c_i); <del> debug!("check_member_constraint: choice_regions={:?}", choice_regions); </del> <ins> debug!(?choice_regions); </ins> // Did the member region wind up equal to any of the option regions? if let Some(o) = choice_regions.iter().find(|&&o_r| self.eval_equal(o_r, m_c.member_region_vid)) { <del> debug!("check_member_constraint: evaluated as equal to {:?}", o); </del> <ins> debug!("evaluated as equal to {:?}", o); </ins> continue; }

Discussion:
This code should pass but it doesn't: This is resurrected. Cc label F-typealiasimpl_trait C-bug T-compiler T-types
Oh heh, I fixed the situation for registering the hidden type but didn't allow implying anything from that.
Change:
|              entering unreachable code |              inside `unreachable_unchecked` at $SRC_DIR/core/src/hint.rs:LL:COL | <del> ::: $DIR/const_unsafe_unreachable_ub.rs:7:18 </del> <ins> ::: $DIR/const_unsafe_unreachable_ub.rs:6:18 </ins> | LL |         false => std::hint::unreachable_unchecked(), <del> |                  ---------------------------------- inside `foo` at $DIR/const_unsafe_unreachable_ub.rs:7:18 </del> <ins> |                  ---------------------------------- inside `foo` at $DIR/const_unsafe_unreachable_ub.rs:6:18 </ins> ... LL | const BAR: bool = unsafe { foo(false) }; <del> |                            ---------- inside `BAR` at $DIR/const_unsafe_unreachable_ub.rs:11:28 </del> <ins> |                            ---------- inside `BAR` at $DIR/const_unsafe_unreachable_ub.rs:10:28 </ins> error: aborting due to previous error

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.