jiebi/CodeConvo huggingface dataset:
Code change:
unsafe impl GlobalAlloc for System { #[inline] unsafe fn alloc(&self, layout: Layout) -> *mut u8 { <ins> // jemalloc provides alignment less than MIN_ALIGN for small allocations. // So only rely on MIN_ALIGN if size >= align. // Also see <https://github.com/rust-lang/rust/issues/45955> and // <https://github.com/rust-lang/rust/issues/62251#issuecomment-507580914>. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::malloc(layout.size()) as *mut u8 } else {

Related discussion:
text: These only need to be aligned at an boundary. If you believe this is incorrect, please show a counter-example for which this doesn't work.
AFAIK it is a normal way of using to make it override the symbol? Don't we still do that in rustc, or when using "jemallocator"? I don't say it is incorrect, I say it is awfully indirect. It's like reading tea leaves. I am looking for a clear definite statement. That doesn't seem to exist though. :( There clearly is some kind of "non-continuity" where all allocations are aligned MINALIGN except for small ones. Or vice versa, all allocations are aligned "size rounded down to power of 2" except for big ones. You are convincingly deriving that non-continuity from standard wording. I don't say you are wrong, but this feels like interpreting ancient scripture. A clear spec looks different. Also, an object of size 2 with alignment requirement 4 is "fundamental" according to your definition, and yet rounding down the size to the next power of 2 does not give the right alignment. So your rule does have exceptions, namely types marked .
Can you show such an object in C and/or Rust ? It's probably the most common way of switching allocators. What does is it requires to be linked to your binary, allowing (and making use of) jemalloc-specific APIs. If you do this, when using directly (not ), you can obviously rely on assumptions that only hold for . But cannot do that because, then it wouldn't work with other allocators.
The goal is not to rely on assumptions that only hold for . The goal is to make sure that we do not make assumptions that don't hold for . Because that's what we used to do, before got fixed. We were assuming something that was true for system but not for : that all allocations, no matter the size, are aligned. To make sure we don't do that again, I want to be sure that all assumptions we are making hold for . That's why I'd like jemalloc to spell out what we can assume.
Ah I forgot about the stride vs. size thing. So such an object does not exist.
Code change:
unsafe impl GlobalAlloc for System { #[inline] unsafe fn alloc(&self, layout: Layout) -> *mut u8 { <ins> // jemalloc provides alignment less than MIN_ALIGN for small allocations. // So only rely on MIN_ALIGN if size >= align. // Also see <https://github.com/rust-lang/rust/issues/45955> and // <https://github.com/rust-lang/rust/issues/62251#issuecomment-507580914>. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::malloc(layout.size()) as *mut u8 } else {

Related discussion:
text: But such a exists, and it is something we want to support in our allocator API (we even have a test for that). And we do have objects with align size, namely all ZST.
Yeah, I agree. The only cases for which the "round to the previous power of two approach" doesn't work is for ZSTs, and types (or allocations) with align size. Since those just cannot happen in C, the C standard doesn't mention them as exceptions. That is, we can only call when that holds, and if it that doesn't hold, we need to call a different API that supports the align size case.
Code change:
//! Performs various peephole optimizations. use crate::transform::{MirPass, MirSource}; <del> use rustc_data_structures::fx::FxHashMap; </del> <ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_hir::Mutability; </ins> use rustc_index::vec::Idx; use rustc_middle::mir::visit::{MutVisitor, Visitor}; use rustc_middle::mir::{ <del> Body, Constant, Local, Location, Mutability, Operand, Place, PlaceRef, ProjectionElem, Rvalue, </del> <ins> Body, Constant, Local, Location, Operand, Place, PlaceRef, ProjectionElem, Rvalue, </ins> }; use rustc_middle::ty::{self, TyCtxt}; use std::mem;

Related discussion:
text: Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.
Code change:
/// Declare a static `LintArray` and return it as an expression. #[macro_export] <del> macro_rules! lint_array { ($( $lint:expr ),*) => ( { static ARRAY: LintArray = &[ $( &$lint ),* ]; ARRAY } ) } </del> <ins> macro_rules! lint_array { ($( $lint:expr ),*,) => { lint_array!( $( $lint ),* ) }; ($( $lint:expr ),*) => {{ static ARRAY: LintArray = &[ $( &$lint ),* ]; ARRAY }} } </ins> pub type LintArray = &'static [&'static &'static Lint];

Related discussion:
text: Basically just change this macro to recognize and discard the trailing comma.
That macro declaration is formatted in a weird way. But anyway it should be enough to add to the rule (unless accepting multiple trailing commas is undesired). I could mentor.
How about this:
Out of curiosity, why doesn't rust allow trailing commas after automatically? Does it make it hard to write some macros? Alternately, why isn't there a (optional) repetition specification (e.g. would be 0 or 1 times)?
The extra rule is fine too. It's just more annoying (extra repetition). And there's no technical reason not to support one-or-none patterns as far as I'm aware.
Made a PR :)
Code change:
/// Returns an iterator over all function arguments. #[inline] <del> pub fn args_iter(&self) -> impl Iterator<Item = Local> { </del> <ins> pub fn args_iter(&self) -> impl Iterator<Item = Local> + ExactSizeIterator { </ins> let arg_count = self.arg_count; <del> (1..=arg_count).map(Local::new) </del> <ins> (1..arg_count + 1).map(Local::new) </ins> } /// Returns an iterator over all user-defined variables and compiler-generated temporaries (all /// locals that are neither arguments nor the return place). #[inline] <del> pub fn vars_and_temps_iter(&self) -> impl Iterator<Item = Local> { </del> <ins> pub fn vars_and_temps_iter(&self) -> impl Iterator<Item = Local> + ExactSizeIterator { </ins> let arg_count = self.arg_count; let local_count = self.local_decls.len(); (arg_count + 1..local_count).map(Local::new)

Related discussion:
text: E.g. in we had to use weird code to check that the iterator is the same length as a slice. After changing the function to have an ExactSizeIterator bound, we should undo the hack <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
What do you mean by "many"? Is this about grepping returns in and replacing them with whenever possible? I'd like to give this a try but not sure what exactly this is asking.
Ah, not libstd, just in the compiler. But yea, you got the right idea, grep for it, see if it can be ExactSizeIterator, if not leave it
Hi, this looks pretty easy and I would actually try to get involved into rustc - could I take this one as starting point for incoming weekend?
Go for it. Just search for returns in the compiler source code and replace them with whenever possible.
claim
Code change:
})); } <ins> let (inh_first, inh_second) = { let mut inh_variants = (0..variants.len()).filter(|&v| { variants[v].iter().all(|f| f.abi != Abi::Uninhabited) }); (inh_variants.next(), inh_variants.next()) }; if inh_first.is_none() { // Uninhabited because it has no variants, or only uninhabited ones. return Ok(tcx.intern_layout(LayoutDetails::uninhabited(0))); } </ins> let is_struct = !def.is_enum() || // Only one variant is inhabited. (inh_second.is_none() &&

Related discussion:
text: Uninhabited variants should ideally be irrelevant to the representation, just like in enums. As a test, this prints out 0 instead of 8: This happens because rustc considers unions more like structs than enums, and the sees a single variant with two fields, one of which is uninhabited. I have a fix for this, but it's slightly easier to bundle it with some other changes I'm working on.
This becomes a problem when making an array of unions: The above code represents a regression (prints 42 on stable, garbage on beta/nightly).
I didn't realize it was a regression to beta - in that case I'll put up an independent fix so that it can be backported if desired.
Although I can't trigger it on the playground, you code is actually triggering an ICE for me: EDIT: I bisected the ICE to somewhere between "rust 1.23.0-nightly ( 2017-11-25)" and "rust 1.23.0-nightly ( 2017-11-26)".
cc
I put up a PR to fix this, but I'm still confused about the ICE (which I moved to ).
Code change:
for i in 0..tupled_arg_tys.len() { let arg = &fx.fn_ty.args[idx]; idx += 1; <ins> if arg.pad.is_some() { llarg_idx += 1; } </ins> arg.store_fn_arg(bx, &mut llarg_idx, place.project_field(bx, i)); }

Related discussion:
text: This code, when compiled for , results in an ICE: Putting smaller integers in does not trigger this, even if you use a ton of them. Edit: It also does not occur when taking it only as argument, or when only returning it. Panic message and backtrace: Rust version: cc
Looks like this could be caused by this common skipping of padding arguments: Combined with this call (which internally also skips padding arguments): When the latter gets used, each padding argument is skipped twice. I assume this is fallout.
triage: P-high Beta regression. Has pending fix.
Code change:
} fn crate_matches(crate_data: &[u8], <del> name: ~str, version: ~str, hash: ~str) -> bool { </del> <ins> name: &str, version: &str, hash: &str) -> bool { </ins> let attrs = decoder::get_crate_attributes(crate_data); match attr::find_crateid(attrs) { None => false, Some(crateid) => { if !hash.is_empty() { let chash = decoder::get_crate_hash(crate_data); <del> if chash != hash { return false; } </del> <ins> if chash.as_slice() != hash { return false; } </ins> } name == crateid.name && (version.is_empty() ||

Related discussion:
text: Built glfw-rs using rust 0.10-pre. When referencing this crate in another source file and building, I get error: internal compiler error: unexpected failure This message reflects a bug in the Rust compiler. We would appreciate a bug report: note: the compiler hit an unexpected failure path. this is a bug Ok(task 'rustc' failed at 'assertion failed: ()', ) This is on OSX 10.9: rustc 0.10-pre ( 2014-02-18 10:16:48 -0800) host: x8664-apple-darwin
This means that you've got two versions of the same lying around, and doesn't like having two versions. This will be fixed by , I just need to land it :(
I have just build the library for the first time, and I can only find one dylib for it on my system (next to the rlib, but I gues that shouldn't cause any problems). Is there another possibility for this error? Gesendet: Mittwoch, 19. Februar 2014 um 01:09 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () This means that you've got two versions of the same libglfw- lying around, and rustc doesn't like having two versions. This will be fixed by , I just need to land it :( — Reply to this email directly or view it on GitHub.
my reading of is that having a dylib and an rlib simultaneously is a problem.
Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem.
sorry, my mistake in parsing the title of .
Yes, indeed, I had several identical dylibs, but it wasn't the glfw-rs.. there were rust libs in /usr/local/lib and /usr/local/lib/rustlib/... Thanks! Gesendet: Mittwoch, 19.
Code change:
} fn crate_matches(crate_data: &[u8], <del> name: ~str, version: ~str, hash: ~str) -> bool { </del> <ins> name: &str, version: &str, hash: &str) -> bool { </ins> let attrs = decoder::get_crate_attributes(crate_data); match attr::find_crateid(attrs) { None => false, Some(crateid) => { if !hash.is_empty() { let chash = decoder::get_crate_hash(crate_data); <del> if chash != hash { return false; } </del> <ins> if chash.as_slice() != hash { return false; } </ins> } name == crateid.name && (version.is_empty() ||

Related discussion:
text: Februar 2014 um 17:15 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem. — Reply to this email directly or view it on GitHub.
so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then?
Nono, the ticket can be closed for now. Thanks for your help! Gesendet: Mittwoch, 19. Februar 2014 um 21:30 UhrVon: "Felix S Klock II" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then? — Reply to this email directly or view it on GitHub.
Code change:
let args = vec!(self_arg); // Add all the fields as a value which needs to be cleaned at the end of <del> // this scope. for (i, ty) in st.fields.iter().enumerate() { </del> <ins> // this scope. Iterate in reverse order so a Drop impl doesn't reverse // the order in which fields get dropped. for (i, ty) in st.fields.iter().enumerate().rev() { </ins> let llfld_a = adt::struct_field_ptr(variant_cx, &*st, value, i, false); variant_cx.fcx.schedule_drop_mem(cleanup::CustomScope(field_scope), llfld_a, *ty);

Related discussion:
text: When a type has no impl, it fields appear to be destructed in order of declaration. When a type does have a impl, that order is apparently reversed. This is very surprising. Example: Prints:
cc who first hit this bug.
The LLVM IR for the Drop glue for : The LLVM IR for the Drop glue for : I don't know why it's getting pointers to each field before calling , they're not used until the cleanup, and they're cleaned up in reverse order. It's also, for some reason, grabbing a pointer to the drop flag (), even though it doesn't use it.
Nominating. Seems pretty strange.
I have an approved commit for this already, it's just failing on the pretty-rpass test at the moment.
I'm OK with disabling the test. Going forward the pretty printer should mainly be used for compiler diagnostics and rustfmt should cover the reformatting use cases, IMO.
Code change:
/// # Examples /// /// ``` <ins> /// #![feature(inner_deref)] /// let mut s = "HELLO".to_string(); </ins> /// let mut x: Result<String, u32> = Ok("hello".to_string()); <del> /// let y: Result<&mut str, &mut u32> = Ok("HELLO"); </del> <ins> /// let y: Result<&mut str, &mut u32> = Ok(&mut s); </ins> /// assert_eq!(x.as_deref_mut().map(|x| { x.make_ascii_uppercase(); x }), y); /// <ins> /// let mut i = 42; </ins> /// let mut x: Result<String, u32> = Err(42); <del> /// let y: Result<&mut str, &mut u32> = Err(&42); </del> <ins> /// let y: Result<&mut str, &mut u32> = Err(&mut i); </ins> /// assert_eq!(x.as_deref_mut().map(|x| { x.make_ascii_uppercase(); x }), y); /// ``` pub fn as_deref_mut(&mut self) -> Result<&mut T::Target, &mut E> {

Related discussion:
text: I would expect the following command to run the libcore doc tests: This used to work, but now all it does it build libcore and its test binaries. No tests are actually being run (which I verified by breaking one of them deliberately). any idea what is happening?
I can confirm, doctests are not being run for std. I think a bigger question is, have they ever worked? Cargo will skip doctests whenever is used, which AFAIK is how std is always built/tested.
I am pretty sure that have used this command before and got test failures when I had screwed up. If you want, I can go back to older versions and verify.
I'll try to figure out what's going on. I tried running with and fortunately nothing looks broken. It's also very possible I am missing something, but I edited some doctests with errors, and a bare doesn't fail.
This was wrong, see below. I'll try to put together a fix.
Ouch. Is there a way we can ensure this does not happen again in the future? Looks like our test suite needs a test suite...
It's pretty hard :/ I guess we can add a dummy doc test that writes some "well known" file and we can assert that the file is present -- perhaps do this per-crate.
OK, it wasn't as bad as I originally reported. This regressed via which is only in 1.45 (beta). I have a fix started at This will require various steps: cargo. to beta. cargo on beta. for new beta release. bootstrap on nightly.
Well, but it does mean that currently on CI we do not run doctests, right? does not change this.
Right, I just mean it hasn't been that long (only about a week).
Code change:
.arg("--manifest-path") .arg(builder.src.join("src/tools/miri/test-cargo-miri/Cargo.toml")); cargo.arg("--target").arg(target.rustc_target_arg()); <del> cargo.arg("--tests"); // don't run doctests, they are too confused by the staging </del> cargo.arg("--").args(builder.config.test_args()); <ins> // `prepare_tool_cargo` sets RUSTDOC to the bootstrap wrapper and RUSTDOC_REAL to a dummy path as this is a "run", not a "test". // Also, we want the rustdoc from the "next" stage for the same reason that we build a std from the next stage. // So let's just set that here, and bypass bootstrap's RUSTDOC (just like cargo-miri already ignores bootstrap's RUSTC_WRAPPER). cargo.env("RUSTDOC", builder.rustdoc(compiler_std)); </ins> // Tell `cargo miri` where to find things. cargo.env("MIRI_SYSROOT", &miri_sysroot); cargo.env("MIRI_HOST_SYSROOT", sysroot);

Related discussion:
text: Currently we do ensure on CI that works, but doctests are enabled as I couldn't figure out how to get this to work within bootstrap. However, that has let slip through. So ideally we can figure out these bootstrap issues and test rustdoc inside on rustc CI.
Here's what currently happens: shows a similar error. So... probably we're using the wrong rustdoc? I assume it's the bootstrap rustdoc, if that's a thing? I can't even see a rustdoc being built in the build log. We want the rustdoc that is produced by stage 0 here, since we are testing the Miri produced by stage 0. How do we get that? Cc
looks to be the reason we're running a random rustdoc here. I suspect we'll need to thread through a custom bootstrap env variable, since IIRC there's no RUSTDOC_WRAPPER that miri can use to thread state. Alternatively it might work to adjust miri such that it remembers which toolchain is running earlier, but I suspect that'll be harder. As-is though it's almost certainly semi-broken for any Rust user doing something like presumably, where their default toolchain isn't nightly?
It seems to be working, AFAIK rustup ensures that nested calls use the -specified toolchain. Or maybe we are just lucky... But yes we should in the outermost wrapper, determine which rustdoc cargo would invoke using the same logic as cargo store that in a miri-private env var invoke that in I assume however we'll also need further changes in how bootstrap invokes cargo-miri to tell it where the right rustdoc lives? Currently we're not even building rustdoc so something surely needs to change in bootstrap. I see this snippet a few times, is that all we need?
Yeah, I'd expect that to be enough to start with at least. Also potentially relevant: If we're already using somewhere in there (we should be, probably?) then that should already get mostly setup, see here: ,
We do that already: Unless you are trying stage 0, you should be able to see rustdoc compilation in the build logs.
This is stage 0. It should still have to build rustdoc, stage 0 Miri needs stage 0 rustdoc (not bootstrap rustdoc) for its doctests.
Code change:
.arg("--manifest-path") .arg(builder.src.join("src/tools/miri/test-cargo-miri/Cargo.toml")); cargo.arg("--target").arg(target.rustc_target_arg()); <del> cargo.arg("--tests"); // don't run doctests, they are too confused by the staging </del> cargo.arg("--").args(builder.config.test_args()); <ins> // `prepare_tool_cargo` sets RUSTDOC to the bootstrap wrapper and RUSTDOC_REAL to a dummy path as this is a "run", not a "test". // Also, we want the rustdoc from the "next" stage for the same reason that we build a std from the next stage. // So let's just set that here, and bypass bootstrap's RUSTDOC (just like cargo-miri already ignores bootstrap's RUSTC_WRAPPER). cargo.env("RUSTDOC", builder.rustdoc(compiler_std)); </ins> // Tell `cargo miri` where to find things. cargo.env("MIRI_SYSROOT", &miri_sysroot); cargo.env("MIRI_HOST_SYSROOT", sysroot);

Related discussion:
text: (...) ah fun, so if we invoke RUSTDOC we'll actually invoke bootstrap's rustdoc wrapper. We'll have to see if having both Miri and that wrapper around will work.^^
Never mind, that was for a build. For stage 0 this doesn't happen. I don't think this can work though... The staging with Miri is a bit weird; we need a stage 1 std as well for our stage 0 tests. Specifically we need a host sysroot that was built with a compiler that "is the same as" Miri, i.e. that is fully compatible. (The is wrong, it's not the compiler that built Miri.) This was needed to make build scripts and proc macros work in .
Yes, and if you want to use the actual rustdoc without wrapper, you can invoke . I tried using env instead of plain "rustdoc" and this is the output:
I had to manually pass from the cargo miri test caller; it turns out we are not passing it by default (or it somehow gets removed later?). Anyway, this is how I tested it:
Yeah currently this does not work due to But you have already come closer than I did. :) Was that with or stage 1? Maybe is ?
I guess that needs to be resolved first before we enable doctests on cargo miri test ? It was stage 1. Yeah, it seems like.
Yes. must continue working. I don't want to always build rustc twice when working on Miri in the tree.^^ But if necessary we could enable doc-tests only for higher stages... that would still be better than the status quo.