jiebi/CodeConvo huggingface dataset:
Change:
This is the reason of nightly packaging failing. I strongly suspect my own for that, although I don't yet know why the artifact is skipped in the first place. I'll investigate further.
Indeed: In  we have some logic to presumably shave off some test time by checking if the rule is host-only, limiting the cross product to hosts array if applicable. However after the hosts array only consists of the build triple, so the output of host rules is effectively filtered to build-triple-only. My apologies. Patch pending.
Opened . Before : (some additional debug info by me, not present in the PR) After , before : After:

Discussion:
} else { &self.build.config.target }; <del> // If --target was specified but --host wasn't specified, don't run // any host-only tests </del> <ins> // Determine the actual targets participating in this rule. // NOTE: We should keep the full projection from build triple to // the hosts for the dist steps, now that the hosts array above is // truncated to avoid duplication of work in that case. Therefore // the original non-shadowed hosts array is used below. </ins> let arr = if rule.host { <del> if self.build.flags.target.len() > 0 && self.build.flags.host.len() == 0 { &hosts[..0] </del> <ins> // If --target was specified but --host wasn't specified, // don't run any host-only tests. Also, respect any `--host` // overrides as done for `hosts`. if self.build.flags.host.len() > 0 { &self.build.flags.host[..] } else if self.build.flags.target.len() > 0 { &[] </ins> } else { <del> hosts </del> <ins> &self.build.config.host[..] </ins> } } else { targets
Change:
So invalidated the assumption that the final stage is stage2, but [this piece of code][] still thought so, so the save-analysis data is never generated. This enraged the bots. Let's polish rustbuild with some more <3 so that we could have a fresh nightly for a nice New Year gift to everyone... []:
BTW the failure on the win32 beta bot (ouch!) is not related to this. It's most likely a Windows hiccup.
Ahhhh big failure of mine. I'm focusing on the generation part (the envvar) and forgot to touch the logic too, and the bots are as red as yesterday (facepalm). Trying to hit the 2017-01-02 nightly instead...

Discussion:
return } <ins> // Package save-analysis from stage1 if not doing a full bootstrap, as the // stage2 artifacts is simply copied from stage1 in that case. let compiler = if build.force_use_stage1(compiler, target) { Compiler::new(1, compiler.host) } else { compiler.clone() }; </ins> let name = format!("rust-analysis-{}", package_vers(build)); let image = tmpdir(build).join(format!("{}-{}-image", name, target)); <del> let src = build.stage_out(compiler, Mode::Libstd).join(target).join("release").join("deps"); </del> <ins> let src = build.stage_out(&compiler, Mode::Libstd).join(target).join("release").join("deps"); </ins> let image_src = src.join("save-analysis"); let dst = image.join("lib/rustlib").join(target).join("analysis");
Change:
Before the recent changes to rustbuild, when changing , it has rebuilt the entire stage0 artifacts and thus the entire compiler. Now its only doing: Later on, you are getting an error like "found possibly newer version of crate which depends on".
cc note, I'm not using any --keep-stage stuff or anything.
workaround is to do manually
I think this is the same as (or that's the same as this), haven't had a chance to investigate yet. My guess is that this is a regression from
yes I think its the same issue. If you are closing dupes, then please close the one that was filed later :)

Discussion:
} pub fn create_sysroot(build: &Build, compiler: &Compiler) { <del> // nothing to do in stage0 if compiler.stage == 0 { return } </del> let sysroot = build.sysroot(compiler); let _ = fs::remove_dir_all(&sysroot); t!(fs::create_dir_all(&sysroot));

/// all files in a directory and updating the stamp if any are newer. fn update_mtime(path: &Path) { let mut max = None; <del> if let Ok(entries) = path.parent().unwrap().read_dir() { </del> <ins> if let Ok(entries) = path.parent().unwrap().join("deps").read_dir() { </ins> for entry in entries.map(|e| t!(e)) { if t!(entry.file_type()).is_file() { let meta = t!(entry.metadata());
Change:
These two errors, which I believe are related, have started happening with rustbuild recently. I think the second is sometimes caused by the first after trying to avoid cleaning out everything; but since this is all nondeterministic from what I can tell I've included it in case it helps diagnose the problem. cc
A few more lines of potentially helpful information:

Discussion:
} pub fn create_sysroot(build: &Build, compiler: &Compiler) { <del> // nothing to do in stage0 if compiler.stage == 0 { return } </del> let sysroot = build.sysroot(compiler); let _ = fs::remove_dir_all(&sysroot); t!(fs::create_dir_all(&sysroot));

/// all files in a directory and updating the stamp if any are newer. fn update_mtime(path: &Path) { let mut max = None; <del> if let Ok(entries) = path.parent().unwrap().read_dir() { </del> <ins> if let Ok(entries) = path.parent().unwrap().join("deps").read_dir() { </ins> for entry in entries.map(|e| t!(e)) { if t!(entry.file_type()).is_file() { let meta = t!(entry.metadata());
Change:
a.out(,0x10065f000) malloc:  error for object 0x7ffed14144d0: pointer being freed was not allocated  set a breakpoint in mallocerrorbreak to debug
I think the problem is that, when translating , if the dest is "ignore", we drop the lvalue but do not zero it.
Which fn we use instead of in "Ignore" case?
This was merged in already, but I also the test case:
I see him there

Discussion:
pure fn ne(other: &Dest) -> bool { !self.eq(other) } } <ins> fn drop_and_cancel_clean(dat: Datum, bcx: block) -> block { let bcx = dat.drop_val(bcx); dat.cancel_clean(bcx); return bcx; } </ins> fn trans_to_datum(bcx: block, expr: @ast::expr) -> DatumBlock { debug!("trans_to_datum(expr=%s)", bcx.expr_to_str(expr));

if bcx.expr_is_lval(a) { let datum = unpack_datum!(bcx, trans_to_datum(bcx, a)); return match dest { <del> Ignore => datum.drop_val(bcx), </del> <ins> Ignore => drop_and_cancel_clean(datum, bcx), </ins> SaveIn(addr) => datum.move_to(bcx, INIT, addr) }; } else {

<ins> // Issue #3878 // Issue Name: Unused move causes a crash // Abstract: zero-fill to block after drop fn main() { let y = ~1; move y; } </ins>  No newline at end of file
Change:
generates linker options of the form . This fails if contains commas, because separates options on commas, so the linker ends up getting a bad path and spurious extra parameters. The solution is to use which passes the next option through literally, so the full rpath can be specified with . The form is fairly verbose, and only needed when there are commas. (This comes up when building with , because it generates paths of the form where "flavors" are things like "shared", "static", "pic", etc.)
Fixed in 1.16

Discussion:
fn rpaths_to_flags(rpaths: &[String]) -> Vec<String> { let mut ret = Vec::new(); for rpath in rpaths { <del> ret.push(format!("-Wl,-rpath,{}", &(*rpath))); </del> <ins> if rpath.contains(',') { ret.push("-Wl,-rpath".into()); ret.push("-Xlinker".into()); ret.push(rpath.clone()); } else { ret.push(format!("-Wl,-rpath,{}", &(*rpath))); } </ins> } return ret; }

assert_eq!(res, "$ORIGIN/../lib"); } } <ins> #[test] fn test_xlinker() { let args = rpaths_to_flags(&[ "a/normal/path".to_string(), "a,comma,path".to_string() ]); assert_eq!(args, vec![ "-Wl,-rpath,a/normal/path".to_string(), "-Wl,-rpath".to_string(), "-Xlinker".to_string(), "a,comma,path".to_string() ]); } </ins> }
Change:
I've seen this quite a lot recently Example logs: Example Travis runs: https://travis- https://travis- https://travis- https://travis- I'm opening a tracking issue so we can collect some more logs and hopefully draw conclusions from them at some point. Until then I'm not really sure how we'd deal with this...
Is there a way to collect the coredump from the segfault so we could attempt to track down the reason behind the segfault? Perhaps we could at least pass to clang so we could try to reproduce locally?
your guess is as good as mine!
If you set , the core dump will end up in .
https://travis- is the first job where we got a stack trace: I wouldn't necessarily call that... illuminating
I wonder if there would be a way to print what the files we're linking are? Maybe that would help since maybe the linker segfaults on an improperly formatted file or something like that; knowing what the files are (names and lengths) may help. I think passing to clang would be good enough, at least as a start.
PRs are always welcome! I don't have any magical tricks up my sleeves to implement tricks like that unfortunately.
Next successful stack trace: https://travis-
another failure of this kind https://travis-
These look like assertion failures: Now the question is how we recover the assert message. Any Mac person knows of a way?
good thinking, I totally missed that before! Looks to be: (that's a disassembly of the executable on my system, which looks to be the same). I believe and sure enough there's in the source
Well the pthreads explains why it's nondeterministic at least...
Random attempt to help this:
Looks like did the trick, we haven't seen this in ~2 weeks, so closing.

Discussion:
RUST_CONFIGURE_ARGS=--build=x86_64-apple-darwin SRC=. os: osx <ins> before_script: &osx_before_script > ulimit -c unlimited </ins> install: &osx_install_sccache > curl -L https://api.pub.build.mozilla.org/tooltool/sha512/d0025b286468cc5ada83b23d3fafbc936b9f190eaa7d4a981715b18e8e3bf720a7bcee7bfe758cfdeb8268857f6098fd52dcdd8818232692a30ce91039936596 | tar xJf - -C /usr/local/bin --strip-components=1 <ins> after_failure: &osx_after_failure > echo 'bt all' > cmds; for file in $(ls /cores); do echo core file $file; lldb -c $file `which ld` -b -s cmds; done </ins> - env: > RUST_CHECK_TARGET=check RUST_CONFIGURE_ARGS=--build=i686-apple-darwin SRC=. os: osx <ins> before_script: *osx_before_script </ins> install: *osx_install_sccache <ins> after_failure: *osx_after_failure </ins> - env: > RUST_CHECK_TARGET=check RUST_CONFIGURE_ARGS=--build=x86_64-apple-darwin --disable-rustbuild SRC=. os: osx <ins> before_script: *osx_before_script </ins> install: *osx_install_sccache <ins> after_failure: *osx_after_failure </ins> - env: > RUST_CHECK_TARGET= RUST_CONFIGURE_ARGS=--target=aarch64-apple-ios,armv7-apple-ios,armv7s-apple-ios,i386-apple-ios,x86_64-apple-ios SRC=. os: osx <ins> before_script: *osx_before_script </ins> install: *osx_install_sccache <ins> after_failure: *osx_after_failure </ins> env: global:
Change:
Test case: When compile with , causes this error:
This is a MIR regression caused by an incorrect fix to .

Discussion:
self.visit_rvalue(&mut rvalue, loc); self.assign(new_temp, rvalue, source_info.span); } else { <del> let mut terminator = if self.keep_original { </del> <ins> let terminator = if self.keep_original { </ins> self.source[loc.block].terminator().clone() } else { let terminator = self.source[loc.block].terminator_mut();

} }; <del> let last = self.promoted.basic_blocks().last().unwrap(); let new_target = self.new_block(); terminator.kind = match terminator.kind { </del> <ins> match terminator.kind { </ins> TerminatorKind::Call { mut func, mut args, .. } => { self.visit_operand(&mut func, loc); for arg in &mut args { self.visit_operand(arg, loc); } <del> TerminatorKind::Call { func: func, args: args, cleanup: None, destination: Some((Lvalue::Local(new_temp), new_target)) } </del> <ins> let last = self.promoted.basic_blocks().last().unwrap(); let new_target = self.new_block(); *self.promoted[last].terminator_mut() = Terminator { kind: TerminatorKind::Call { func: func, args: args, cleanup: None, destination: Some((Lvalue::Local(new_temp), new_target)) }, ..terminator }; </ins> } ref kind => { span_bug!(terminator.source_info.span, "{:?} not promotable", kind); } }; <del> *self.promoted[last].terminator_mut() = terminator; </del> }; self.keep_original = old_keep_original;

3 } <ins> const fn bar(x: i64) -> i64 { x*2 } </ins> fn main() { let val = &(foo() % 2); assert_eq!(*val, 1); <ins> let val2 = &(bar(1+1) % 3); assert_eq!(*val2, 1); </ins> }
Change:
Seen twice now with the failure message: Logs: I'll probably email them about retries and such come next week, wanted to start collecting logs in the meantime.
sigh
We've got enough examples now I've about this.
An has been created for this.

Discussion:
on: branch: auto DEPLOY: 1 <ins> max_error_retry: 5 </ins> # This provider is the same as the one above except that it has a slightly # different upload directory and a slightly different trigger

on: branch: auto DEPLOY_ALT: 1 <ins> max_error_retry: 5 </ins> # init: #   - ps: iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
Change:
It's always false.
I'm on Linux Mint, the kernel version is
The file system is ext4
Duplicate of ; not a bug. EDIT: Or rather, is a documentation bug.
Update the docs for to note that a common source of confusion is to call this on the result of not .
Hi. I'm new to rust, and have been looking through the E-easy tagged bugs for one it would be easy to start with. (Thank you very much for making easy bugs available as on-ramps, it is very very much appreciated.) I think the appropriate change is in in the documentation for issymlink(). Adding a second line to the description warning that you should use symlinkmetadata by default, and changing the example to use fs::symlink_metadata() not fs::metadata(). I have made and tested that change locally. Does that sound right?
Yes. I would suggest just submitting a PR. Reviewing (commenting on) code directly both spares you the effort describing the changes and us from parsing the description.
I believe this one is done?
Assuming I'm right, yes, I think my commit fixed this particular issue, did everything suggested, and is now merged safely to master.
Addressed by in . Thanks again!

Discussion:
/// Test whether this file type represents a symbolic link. /// <ins> /// The underlying [`Metadata`] struct needs to be retrieved /// with the [`fs::symlink_metadata`] function and not the /// [`fs::metadata`] function. The [`fs::metadata`] function /// follows symbolic links, so [`is_symlink`] would always /// return false for the target file. /// /// [`Metadata`]: struct.Metadata.html /// [`fs::metadata`]: fn.metadata.html /// [`fs::symlink_metadata`]: fn.symlink_metadata.html /// [`is_symlink`]: struct.FileType.html#method.is_symlink /// </ins> /// # Examples /// /// ``` /// # fn foo() -> std::io::Result<()> { /// use std::fs; /// <del> /// let metadata = try!(fs::metadata("foo.txt")); </del> <ins> /// let metadata = try!(fs::symlink_metadata("foo.txt")); </ins> /// let file_type = metadata.file_type(); /// /// assert_eq!(file_type.is_symlink(), false);
Change:
[ ] It's weird that and are allowed, but not . [ ] Even if that's intentional, the error message seems off.
The provided code compiles fine both in 1.36 and the 2019-08-12 nightly. I did a quick search through the test suite and there's none for this particular case. Marking as such. modify labels: E-needstest

Discussion:
<ins> // check-pass pub struct X { pub a: i32, pub b: i32, } fn main() { const DX: X = X { a: 0, b: 0 }; const _X1: X = X { a: 1, ..DX }; let _x2 = X { a: 1, b: 2, ..DX }; const _X3: X = X { a: 1, b: 2, ..DX }; } </ins>
Change:
I haven't checked, but I'm 95% certain that they do this because some characters expand into multiple characters when casefolding which wouldn't fit into the buffer of the , so we need a new buffer. Since we don't know the size beforehand, we just return a . Probably should link to char.tolowercase and char.touppercase.
(With permission from &

Discussion:
/// 'Lowercase' is defined according to the terms of the Unicode Derived Core Property /// `Lowercase`. /// <ins> /// Since some characters can expand into multiple characters when changing /// the case, this function returns a [`String`] instead of modifying the /// parameter in-place. /// </ins> /// [`String`]: string/struct.String.html /// /// # Examples

/// 'Uppercase' is defined according to the terms of the Unicode Derived Core Property /// `Uppercase`. /// <ins> /// Since some characters can expand into multiple characters when changing /// the case, this function returns a [`String`] instead of modifying the /// parameter in-place. /// </ins> /// [`String`]: string/struct.String.html /// /// # Examples
Change:
Hi. I am testing out rust 1.15.0 beta and I came across a problem installing from source: Debian GNU/Linux 8 x8664 (1.15.0-beta.5) and directories in . Only the directory is present. I am new to rust (just a couple of days) so forgive me if I've overlooked something. I'm pretty sure I installed 1.14.0 similarly and was installed OK. That was using the old makefiles-based build system.
IIRC this hasn't ever worked, but would be a great bug to fix with rustbuild!
I've made a fix to this issue, you just need to apply this patch: This will check the structure for the targets provided on the stage, it will then remove any target that is equal to the host (since the host will already be installed) and call the install function on it resulting in the installation of all the for all the targets. I don't know if this is the best approach or if there is some case that will fail and I'm not aware. But, if it is a ok patch, can we apply it to the next version of rust since it seems that this is a major problem for a lot of users (at least for me it is since I'm trying to make the rust ebuild for gentoo support multiple targets and this bug is just what is preventing me). Thanks
looks like a great start to me, you're more than welcome to send a PR! I think that we'llalso want to update for the new dependencies, but other than that look great to me.
I believe this is fixed now that landed, closing. Please let me know if I'm wrong though!

Discussion:
install_sh(&build, "docs", "rust-docs", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); } <ins> for target in build.config.target.iter() { install_sh(&build, "std", "rust-std", stage, target, &prefix, &docdir, &libdir, &mandir, &empty_dir); } </ins> if build.config.rust_save_analysis { install_sh(&build, "analysis", "rust-analysis", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); } <del> install_sh(&build, "std", "rust-std", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); </del> install_sh(&build, "rustc", "rustc", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); t!(fs::remove_dir_all(&empty_dir));
Change:
in the rust docs it says why is filtermap not equal to filter().map() this makes no sense it should ask why is filtermap not equal to map().filter(). also would be nice to explain that filtermap is is basically map().filter(is_some).map(unwrap) might make it easier to grasp.
Addressed in

Discussion:
/// closure returns [`None`], it will try again, and call the closure on the /// next element, seeing if it will return [`Some`]. /// <del> /// Why `filter_map` and not just [`filter`].[`map`]? The key is in this </del> <ins> /// Why `filter_map` and not just [`filter`] and [`map`]? The key is in this </ins> /// part: /// /// [`filter`]: #method.filter
Change:
I've noticed this recently on the Travis/AppVeyor logs, but I haven't tracked it down yet to see what caused it.
Appears caused by perhaps caused by
ummmmmmmmm perhaps..... the tests are not failing though? Do you have a link to an example?
Oh right sorry I meant only that output is being generated, not that tests are failing. Most of the tests expect a failure which is the reason so many errors are printed. An example is here (https://travis-) from the logs of that PR (how nifty I can check that out!). You should be able to reproduce this locally as well via

Discussion:
should_panic: testing::ShouldPanic::No, }, testfn: testing::DynTestFn(box move |()| { <ins> let panic = io::set_panic(None); let print = io::set_print(None); </ins> match { rustc_driver::in_rustc_thread(move || { <ins> io::set_panic(panic); io::set_print(print); </ins> runtest(&test, &cratename, cfgs,
Change:
on reddit points out that can be called multiple times and result in getting multiple of the exact same data.
Awesome!
I suggest we change it to &mut and run it through crater to see the impact. We can change it or immediately deprecate it. We can make a point release or wait until 1.16.

Discussion:
/// assert_eq!(into_iter.next().unwrap(), 'z'); /// ``` #[stable(feature = "vec_into_iter_as_slice", since = "1.15.0")] <del> pub fn as_mut_slice(&self) -> &mut [T] { </del> <ins> pub fn as_mut_slice(&mut self) -> &mut [T] { </ins> unsafe { slice::from_raw_parts_mut(self.ptr as *mut T, self.len()) }
Change:
The build system that we just turned on is not actually in the source code. cc
This is on beta and nightly too.
Reeopening until the backport is fixed because I'm putting this on the release milestone.
Backported in as

Discussion:
"README.md", "RELEASES.md", "configure", <del> "Makefile.in" </del> <ins> "Makefile.in", "x.py", </ins> ]; let src_dirs = [ "man",
Change:
On the page there is a comparison of the collection types in the standard library and it says under "Use a BTreeMap when:" "You want a sorted map.". It was not immediately clear to me that the map's Key/Value pairs are in fact sorted by its keys. This was only fully clarified by asking the helpful folks over on IRC. Steve Klabnik then encouraged me to open an issue here asking for a change in the docs clarifying the point made above. This point in the list/comparison should probably say something more like "You want a map sorted by its keys." to avoid any unnecessary ambiguity.
I agree wholeheartedly, thanks for filing! I'm willing to help mentor anyone who wants to fix this bug.

Discussion:
//! * You want to find the largest or smallest key that is smaller or larger //!   than something. //! * You want to be able to get all of the entries in order on-demand. <del> //! * You want a sorted map. </del> <ins> //! * You want a map sorted by its keys. </ins> //! //! ### Use the `Set` variant of any of these `Map`s when: //! * You just want to remember which keys you've seen.
Change:
As far as I know, it's no longer possible to not use rustbuild, so ./configure offering --disable-rustbuild doesn't make much sense and it still accepts it:

Discussion:
opt dist-host-only 0 "only install bins for the host architecture" opt inject-std-version 1 "inject the current compiler version of libstd into programs" opt llvm-version-check 1 "check if the LLVM version is supported, build anyway" <del> opt rustbuild 1 "use the rust and cargo based build system" </del> opt codegen-tests 1 "run the src/test/codegen tests" opt option-checking 1 "complain about unrecognized options in this configure script" opt ninja 0 "build LLVM using the Ninja generator (for MSVC, requires building in the correct environment)"