jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

Related discussion:
text: cc
So, I've been putting off commenting here to let these ideas sit, but let me leave a comment. I think I've reached a conclusion. TL;DR. I think we should mark these types as internal, but I think there are some better options for fixing this in the medium term, and this interaction should be taken into account as part of the "MIR 2.0" effort to rework places. Auto traits weren't really intended as a tool for probing layout, but rather semantic considerations. This is why traits like can be implemented by users. So I don't really think that auto traits give any sort of guarantee about their layout. Rather, this question is about is simply "what are the constituent types exposed by a generator", and this should correspond to the types that user code can directly access. The raw pointers here are not directly accessible. The values that are accessible are the "live values" that the user's code may later use -- and of course the code currently makes the constituent types be a superset of those, based on the AST structure. Of course, the real root cause of this error is a simplifying change to the definition of in MIR. It used to be that a Place had this grammar: but now we changed to just , which is why we are required to introduce the new temporary (and that holds the address of the ). As we've been talking about this change, I've been saying that we should be considering the older definition of as the one that is used by various analyses (and in particular by borrow check). This particular transformation of removing statics doesn't affect borrow check, but we failed to take into account the fact that the set of live variables can effect the definition of what is live in a generator. In particular, compiling for some expression requires a temporary unless corresponds to a place -- those places used to include statics like , but they no longer do. But I think that for analysis purposes, it should appear as if they do. We could fix this in two ways. We could write some code motion / duplication that takes temporaries like that are live across a yield and creates a fresh variable after the yield. The idea would be to make them never* live across a yield.
Code change:
<ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

Related discussion:
text: We can do this because that operation is a compile-time constant, really, and thus the value doesn't need to be live across a yield. This might be worth doing as a size optimization regardless. Secondly, some of the proposals we've been kicking around for going further with simplifying include the idea of a distinct sort of temporaries that explicitly represent a "partially constructed that hasn't been used by the user". The idea was to allow borrowck (and other analyses) to trivially reconstruct the . We might want to add this interaction with auto-traits into the consideration for that design, and maybe it takes us some place (e.g., these special temporaries are not considered live for the purposes of auto traits). Having written out both of those options, though, I sort of lean towards the first, at least for this specific issue.
I think these references and raw pointers created by MIR construction should be marked as . They are not visible at the language level. They can be viewed as just prefetching the address of a static, so the compiler could pick any type it likes for it (, , , some compiler internal type) so it must not affect auto trait inference. Drop flags are ignored for similar reasons. You cannot use an auto trait like this to detect them: So I think that should be reverted and the temporary static references should be marked as .
Note: opened instituting this change and I r+'d it, since fixing the regression seems pretty important and time is of the essence; there is general consensus here on the thread; this is only restoring older behavior. In particular, there were some suggestions that this might be a lang team issue; I think there is some 'intersection' and I don't want the perception that I'm trying to shortcircuit discussion. That said, I also think this is primarily a compiler team matter, since it's a deviation from the old behavior, and further this deviation was caused by altering the MIR away from the "natural, Rust-based" definition and towards a lower-level definition.
Code 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. macro_rules! invalid { _ => (); //~^ ERROR Invalid macro matcher } fn main() { } </ins>

Related discussion:
text: A simple malformed macro makes the compiler crash. Code: Playpen error: Playpen:
Another case: Playpen:
I had a crash in a bad macro which hits the same bug as Note that his/her error has the following which is a different stack trace: I'm on the latest beta; not nightly.
I think you and I are getting a different panic from this bug. I've opened since the panic is in a different location in the code.
Code change:
<ins> // build-pass #![feature(dyn_star)] //~^ WARN the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes fn main() { let x: dyn* Send = &(); let x = Box::new(x) as Box<dyn Send>; } </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</details
label +F-dyn_star
:laughing: the code thinks that this is a upcast, I think, rather than an unsize coercion. shouldn't be too hard to fix, but I may leave it for someone else. edit: nvm I'll just fix it.
Code change:
<ins> // build-pass // compile-flags: --crate-type lib // Regression test for ICE which occurred when const propagating an enum with three variants // one of which is uninhabited. pub enum ApiError {} #[allow(dead_code)] pub struct TokioError { b: bool, } pub enum Error { Api { source: ApiError, }, Ethereum, Tokio { source: TokioError, }, } struct Api; impl IntoError<Error> for Api { type Source = ApiError; fn into_error(self, error: Self::Source) -> Error { Error::Api { source: (|v| v)(error), } } } pub trait IntoError<E> { /// The underlying error type Source; /// Combine the information to produce the error fn into_error(self, source: Self::Source) -> E; } </ins>

Related discussion:
text: I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .
Code change:
use core::intrinsics::abort; use core::iter; use core::marker::{PhantomData, Unpin, Unsize}; <del> use core::mem::{self, align_of_val, size_of_val}; </del> <ins> use core::mem::{self, align_of_val_raw, size_of_val}; </ins> use core::ops::{CoerceUnsized, Deref, DispatchFromDyn, Receiver}; use core::pin::Pin; use core::ptr::{self, NonNull};

Related discussion:
text: I tried this code: When I run it under , I get this: Creating a reference from such pointer looks suspicious indeed. I could send a pull request that adds a condition there, but I want to ask first if this is being done because „we are , we can“, or if this is something that really should be fixed. : (but I've looked at the git sources and the thing is still there) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it should only be UB to dereference the pointer you get from , so I'm not sure why Miri thinks there's UB happening. Just in case, prioritize
Because that pointer is being turned into a reference to feed to internally. And references are supposed to be always valid.
Looks like fixed this for but missed it in .
Yes, seems this needs to use .
I renamed the issue to reflect that the bug is actually in (which calls).
Cc
Assuming you use the default flags for Miri, that change should not be required to make Miri pass, so I'd be surprised if doing the same change for would make any difference here. If it does, that seems like a bug in Miri that I should investigate.
Ah, but the in is indeed a problem (the PR was mostly about so I got side-tracked; the is what should not have any effect here). Miri ensures that references are at least dereferencable, so yeah that would explain the problem here. Good catch!
Yep, I apparently missed this somehow in . Fixing the indicated line to use should be enough to fix it; I'm preparing the patch currently. claim
Hm, Miri still complains, even after the fix landed... it seems Miri doesn't like being called with dangling pointers. I'll have to look into this.
IIRC, when , I changed the type of the intrinsic to take a raw pointer rather than a reference, but miri wasn't touched, so that would make sense miri's still expecting a proper reference.
Patch arrived really fast, we are assigning "post-mortem" a priority of as discussed as part of the and removing .
Code change:
fn hash_stable<W: StableHasherResult>(&self, hcx: &mut StableHashingContext<'gcx>, hasher: &mut StableHasher<W>) { <del> let hash_spans = match self.node { </del> <ins> let (is_const, hash_spans) = match self.node { </ins> hir::ItemStatic(..)      | <del> hir::ItemConst(..)       | hir::ItemFn(..)          => { hcx.hash_spans() </del> <ins> hir::ItemConst(..)       => { (true, hcx.hash_spans()) } hir::ItemFn(_, _, constness, ..) => { (constness == hir::Constness::Const, hcx.hash_spans()) </ins> } hir::ItemUse(..)         | hir::ItemExternCrate(..) |

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
} impl<T: ?Sized+Unsize<U>, U: ?Sized> CoerceUnsized<Box<U>> for Box<T> {} <ins> #[stable(feature = "box_slice_clone", since = "1.3.0")] impl<T: Clone> Clone for Box<[T]> { fn clone(&self) -> Self { let mut new = BoxBuilder { data: RawVec::with_capacity(self.len()), len: 0 }; let mut target = new.data.ptr(); for item in self.iter() { unsafe { ptr::write(target, item.clone()); target = target.offset(1); }; new.len += 1; } return unsafe { new.into_box() }; // Helper type for responding to panics correctly. struct BoxBuilder<T> { data: RawVec<T>, len: usize, } impl<T> BoxBuilder<T> { unsafe fn into_box(self) -> Box<[T]> { let raw = ptr::read(&self.data); mem::forget(self); raw.into_box() } } impl<T> Drop for BoxBuilder<T> { fn drop(&mut self) { let mut data = self.data.ptr(); let max = unsafe { data.offset(self.len as isize) }; while data != max { unsafe { ptr::read(data); data = data.offset(1); } } } } } } </ins>

Related discussion:
text: We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.
Code change:
css_file_extension: css_file_extension.clone(), markdown_warnings: RefCell::new(vec![]), created_dirs: RefCell::new(FxHashSet()), <ins> sort_modules_alphabetically, </ins> }; // If user passed in `--playground-url` arg, we fill in crate name here

Related discussion:
text: Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.
Code change:
css_file_extension: css_file_extension.clone(), markdown_warnings: RefCell::new(vec![]), created_dirs: RefCell::new(FxHashSet()), <ins> sort_modules_alphabetically, </ins> }; // If user passed in `--playground-url` arg, we fill in crate name here

Related discussion:
text: The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !
Code change:
/// of each element in the array. /// /// On arithmetic overflow, returns `None`. <ins> #[inline] </ins> pub fn repeat(&self, n: usize) -> Option<(Self, usize)> { let padded_size = match self.size.checked_add(self.padding_needed_for(self.align)) { None => return None,

Related discussion:
text: Rustc used to be able to replace with a constant when optimizing, not at the moment. It simply looks like a Layout method that is not inlinable. (This is a regression strictly speaking — stable & beta can do this optimization, but not nightly.) Code to reproduce:
Are there any ways to write automated tests to check for "regressions" like this? Assertions against LLVM bitcode?
Yes can be used for this, e.g. Assuming this is run against the bitcode after optimization, that is.
cc -- seems LLVM related
Nope. Just () that is not marked as inline.
cc
I didn't confirm that making Layout::repeat as inline fixes this, so please confirm that/add a test before closing.
Code change:
false } }; if !eligible { return Ok(None); } <ins> // HACK: We may have overlapping `dyn Trait` built-in impls and // user-provided blanket impls. Detect that case here, and return // ambiguity. // // This should not affect totally monomorphized contexts, only // resolve calls that happen polymorphically, such as the mir-inliner // and const-prop (and also some lints). let self_ty = rcvr_args.type_at(0); if !self_ty.is_known_rigid() { let predicates = tcx .predicates_of(impl_data.impl_def_id) .instantiate(tcx, impl_data.args) .predicates; let sized_def_id = tcx.lang_items().sized_trait(); // If we find a `Self: Sized` bound on the item, then we know // that `dyn Trait` can certainly never apply here. if !predicates.into_iter().filter_map(ty::Clause::as_trait_clause).any(|clause| { Some(clause.def_id()) == sized_def_id && clause.skip_binder().self_ty() == self_ty }) { return Ok(None); } } </ins> // Any final impl is required to define all associated items. if !leaf_def.item.defaultness(tcx).has_value() { let guard = tcx.sess.delay_span_bug(

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: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
// For LTO purposes, the bytecode of this library is also inserted // into the archive. let bc = obj_filename.with_extension("bc"); <ins> let bc_deflated = obj_filename.with_extension("bc.deflate"); </ins> match fs::File::open(&bc).read_to_end().and_then(|data| { <del> fs::File::create(&bc).write(flate::deflate_bytes(data).as_slice()) </del> <ins> fs::File::create(&bc_deflated).write(flate::deflate_bytes(data).as_slice()) </ins> }) { Ok(()) => {} Err(e) => {

Related discussion:
text: Passing rustc the flag and passing may produce different files (that is, outputs). This is true of rust-core (see below), though was not the case for a simpler ("Hello, world!") test file. Test script: Diff output indicates binary files differ. Tested with , rust-core on . rustc compiled from master on Arch Linux. If this is, in fact, expected behavior- sorry for the trouble, unexpected to me.
Can you provide a diff between the outputs? This is likely a known issue, but I would like to be sure.
.bc is a binary format, so just gives "Binary files and differ" as its output. On my machine, is 19K and is 62K. I'm not familiar enough with the format to extract much more data.
I note the difference persists when the second line is (two separate flags), though both produce both artifacts.
Can you pass and diff those outputs?
With emit flags as and respectively, there is no difference in and (according to diff.)
It seems that every bytecode is invalid only when a rlib is produced. It stopped working between rust-git-0.9.1301 and 1362 (shortly before 2014-02-23 15:37:05 -0800). Going back thorugh the log, I found I believe that creates deflated bytecode. Perhaps should be stored with extension or .
Code change:
/// # Examples /// /// ```no_run <del> /// #![feature(rw_exact_all_at)] </del> /// use std::io; /// use std::fs::File; /// use std::os::unix::prelude::FileExt;

Related discussion:
text: The and traits contain convenience methods and wrapping and . This issue tracks addition of similar methods to trait's and . This is implemented in .
if this is a tracking issue, maybe it should have the label
We should eventually add similar methods to .
I know nothing about developing on Windows so I can't do it myself but I guess a PR would be accepted. Can we stabilize this? Is there anything that still needs to be done?
Seems reasonable to me! fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
What's the next step? Should I make a PR to stabilize? Sorry but I don't fully understand how things work yet.
indeed that should be all that's necessary! If you'd like to make the PR you're also more than welcome to do so!