jiebi/CodeConvo huggingface dataset:
Change:
: Since the closure to can choose to return , this implementation is overly broad. It would need to take the closure into account, which seems... not possible. Here's a reproduction showing the unexpected behavior when the closure returns : This example requires nightly for the feature to demonstrate, but the effect can be felt in stable Rust.

Discussion:
} } <del> #[unstable(feature = "fused", issue = "35602")] impl<B, I, St, F> FusedIterator for Scan<I, St, F> where I: FusedIterator, F: FnMut(&mut St, I::Item) -> Option<B> {} </del> /// An iterator that maps each element to an iterator, and yields the elements /// of the produced iterators. ///
Change:
crates, when compiled with , generate invalid warnings about missing documentation. The following simple crate demonstrates the error. : : I expect this to compile cleanly since there is a crate-level doc comment and a doc comment for the public function. Instead, compiling gives: which makes no sense since line 1 is a comment. Compiler version - latest stable, but fails on yesterday's nightly (2017-05-14) too: :
cc (tracking issue)
I am hitting the same problem. This issue is preventing for proc-macro crates (I haven't found a work around). That's pretty annoying :-/ Rust 1.24.1.
Same here. Is there a fix for this?
Seems to still be happening.
Fails on stable, beta, and nightly still.
On a proc-macro crate in , I'm getting two warnings: and with no line numbers.
shows that the compiler is inserting a with a . I didn't find the code that does the insertion in a very brief search.
So I guess the low-effort fix here is slapping on that ? EDIT: Looks like the code that generates that is ?
Thanks Turns out my working copy wasn't updated like I thought so searching through it didn't work. PR just submitted.

Discussion:
// Creates a new module which looks like: // <ins> //      #[doc(hidden)] </ins> //      mod $gensym { //          extern crate proc_macro; //

}); let span = DUMMY_SP.apply_mark(mark); <ins> let hidden = cx.meta_list_item_word(span, Symbol::intern("hidden")); let doc = cx.meta_list(span, Symbol::intern("doc"), vec![hidden]); let doc_hidden = cx.attribute(span, doc); </ins> let proc_macro = Ident::from_str("proc_macro"); let krate = cx.item(span, proc_macro,

span, span, ast::Ident::with_empty_ctxt(Symbol::gensym("decls")), <del> vec![], </del> <ins> vec![doc_hidden], </ins> vec![krate, decls_static], ).map(|mut i| { i.vis = respan(span, ast::VisibilityKind::Public);

<ins> //! Verify that the `decls` module implicitly added by the compiler does not cause `missing_docs` //! warnings. // compile-pass // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] #![deny(missing_docs)] extern crate proc_macro; use proc_macro::*; /// Foo1. #[proc_macro] pub fn foo1(input: TokenStream) -> TokenStream { input } </ins>
Change:
The nightly builds are currrently failing as the cargo install as part of the nightly want to unconditionally place stuff in : the log file above says:
As a side-question: Is it not feasible to use a pre-built Rust (e.g. installed through ) for Compiler Explorer, instead of installing it from source?
- I'm not installing via source here (I don't think?). I'm running and then manaully patching the to let me run the binaries directly by path. CE installs to a shared NFS drive that all the various instances all mount. If can be made to install somewhere "shared" like this, I can move to it. Importantly I need to be able to execute the full path to the rust compiler ( or similar) without any per-compiler environment variables being required.
Sorry, I misunderstood. Interesting. I'm not really knowledgeable on rustup and environments like this. Perhaps or could answer this. <sAlthough... Now that I think about it, I think rustup just invokes when installing a toolchain, so this would be broken with rustup too.</s
Probably related to in .
rustup doesn't use (it supports windows) you can use and to control where the toolchains and rustup proxies are installed respectively. I'm not sure if this will solve your use-case?
Or more precisely, rust-lang/rust-installer defines . I understand why that's not under the prefix (like ), but it seems surprising that it doesn't at least respect . cc
Actually, I think it should use by default, then let users choose if they're sure they want it installed globally. just puts these files in .
When using x.py it respects DESTDIR just like all the others (libdir, bindir, etc). Is there a way to reproduce?
$ wget $ tar xf cargo-nightly-x8664-unknown-linux- $ ./cargo-nightly-x8664-unknown-linux- --prefix=./usr install: creating uninstall script at install: installing component 'cargo' install: backing up existing file at /etc/bashcompletion.d/cargo mv: cannot move '/etc/bashcompletion.d/cargo' to '': Permission denied install: error: failed to back up /etc/bash_completion.d/cargo. see logs at ''
I think it should just be like this to be prefixed by default: (i.e. don't assume that we really want the global by default)
See It seems pretty standard not to respect prefix for sysconfdir, but not respecting DESTDIR was indeed a mistake

Discussion:
<del> Subproject commit daa2a05ebe7b8d07a309e8891ebc548652362954 </del> <ins> Subproject commit 655a137a8bd0dda1cc71fb82661446e215563d6f </ins>
Change:
Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?

Discussion:
/// Cancel the diagnostic (a structured diagnostic must either be emitted or /// canceled or it will panic when dropped). <del> /// BEWARE: if this DiagnosticBuilder is an error, then creating it will /// bump the error count on the Handler and canceling it won't undo that. /// If you want to decrement the error count you should use `Handler::cancel`. </del> pub fn cancel(&mut self) { self.level = Level::Cancelled; }

return; } <del> let is_error = match self.level { </del> <ins> self.handler.emit_db(&self); self.cancel(); } pub fn is_error(&self) -> bool { match self.level { </ins> Level::Bug | Level::Fatal | Level::PhaseFatal |

Level::Cancelled => { false } <del> }; self.handler.emit_db(&self); self.cancel(); if is_error { self.handler.bump_err_count(); </del> } <del> // if self.is_fatal() { //     panic!(FatalError); // } </del> } /// Convenience function for internal use, clients should use one of the

// one: if self.emitted_diagnostics.borrow_mut().insert(diagnostic_hash) { self.emitter.borrow_mut().emit(db); <ins> if db.is_error() { self.bump_err_count(); } </ins> } } }

35 |     #[rustc_deprecated = "1500"] impl S { } |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 9 previous errors </del> <ins> error: aborting due to 8 previous errors </ins>

35 |     #[stable = "1300"] impl S { } |     ^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 9 previous errors </del> <ins> error: aborting due to 8 previous errors </ins>

35 |     #[unstable = "1200"] impl S { } |     ^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 9 previous errors </del> <ins> error: aborting due to 8 previous errors </ins>

14 | } | - immutable borrow ends here <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins>

20 |     m!(MyTrait<>); //~ ERROR generic arguments in macro path |               ^^ <del> error: aborting due to 5 previous errors </del> <ins> error: aborting due to 4 previous errors </ins>
Change:
I tried to build a different ABI/triplet than the one rustbuild automatically guesses by using the command line option. As suggested in , But it didn't work and failed with: Setting "build" in works correctly. The script is responsible for downloading the stage0 compiler and building bootstrap (rustbuild), but it only checks which stage0 to download and use in It doesn't look at the command line at all for deciding this, which I think is the cause for this. See: .

Discussion:
def bootstrap(): parser = argparse.ArgumentParser(description='Build rust') parser.add_argument('--config') <ins> parser.add_argument('--build') </ins> parser.add_argument('--clean', action='store_true') parser.add_argument('-v', '--verbose', action='store_true')

rb.update_submodules() # Fetch/build the bootstrap <del> rb.build = rb.build_triple() </del> <ins> rb.build = args.build or rb.build_triple() </ins> rb.download_stage0() sys.stdout.flush() rb.build_bootstrap()
Change:
E.g., the expression with unknown type is the variable use , but the error highlight covers the entire sub-expression of . I assume this is due to us doing something sub-optimal with the spans here in the HIR lowering.
is worried that similar issues are arising with other desugarings, i.e. that this might be an across-the-board regression. Worth investigating.
: gives
triage: P-medium Doesn't seem like a "stop everything" sort of problem, but would be good to figure it out. However, it does not appear to be a regression: e.g., the above test case behaves the same in 1.16.0 as well.

Discussion:
let rcvr = &args[0]; let rcvr_t = self.check_expr_with_needs(&rcvr, needs); // no need to check for bot/err -- callee does that <del> let rcvr_t = self.structurally_resolved_type(expr.span, rcvr_t); </del> <ins> let rcvr_t = self.structurally_resolved_type(args[0].span, rcvr_t); </ins> let method = match self.lookup_method(rcvr_t, segment,

<ins> // Copyright 2018 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. // When the type of a method call's receiver is unknown, the span should point // to the receiver (and not the entire call, as was previously the case before // the fix of which this tests). fn shines_a_beacon_through_the_darkness() { let x: Option<_> = None; x.unwrap().method_that_could_exist_on_some_type(); //~^ ERROR 17:5: 17:15: the type of this value must be known in this context } fn courier_to_des_moines_and_points_west(data: &[u32]) -> String { data.iter() //~ ERROR 22:5: 23:20: the type of this value must be known in this context .sum::<_>() .to_string() } fn main() {} </ins>

<ins> error[E0619]: the type of this value must be known in this context --> $DIR/issue-42234-unknown-receiver-type.rs:17:5 | 17 |     x.unwrap().method_that_could_exist_on_some_type(); |     ^^^^^^^^^^ error[E0619]: the type of this value must be known in this context --> $DIR/issue-42234-unknown-receiver-type.rs:22:5 | 22 | /     data.iter() //~ ERROR 22:5: 23:20: the type of this value must be known in this context 23 | |         .sum::<_>() | |___________________^ error: aborting due to 2 previous errors </ins>
Change:
someone in IRC mentioned should actually point to . i would fix it myself, i don't really understand what the sentence means that uses that link (but i'm also pretty tired).
It doesn't seem logical to me: this is returned from a method, so it's normal that we're talking about the method, no?
So, is how you get a , but that sentence is trying to point to .
Then we just rephrase it in order to make it sound more logical. :)

Discussion:
/// /// [`Ok`]: ../../std/result/enum.Result.html#variant.Ok /// [`Err`]: ../../std/result/enum.Result.html#variant.Err <del> /// [`into_inner`]: ../../std/sync/struct.Mutex.html#method.into_inner </del> <ins> /// [`into_inner`]: ../../std/sync/struct.PoisonError.html#method.into_inner </ins> #[stable(feature = "rust1", since = "1.0.0")] pub type LockResult<Guard> = Result<Guard, PoisonError<Guard>>;
Change:
It seems that building compiler docs is broken, in a fresh clone with: fails with:
rust-lang/libc seems very relevant. I guess the libc submodule needs to be updated.

Discussion:
<del> Subproject commit 03562b0cb26a00f49d4eaf18ca3e49608110b0c8 </del> <ins> Subproject commit 2015cf17a6a2a2280e93d9c57214ba92dbbaf42f </ins>
Change:
It seems unclear to me from [its documentation][1] when exactly will flush. The documentation of the struct says that it flushes "whenever a newline […] is detected", but the existence and documentation of the constructor suggests that has an internal buffer of some set capacity. What happens if a line written to the exceeds the capacity of the internal buffer? Can also flush before a newline is detected? [1]:
Yes, will also flush whenever the internal buffer is full (1024 bytes last I checked).

Discussion:
/// /// The buffer is written out before returning the writer. /// <ins> /// # Errors /// /// An `Err` will be returned if an error occurs while flushing the buffer. /// </ins> /// # Examples /// /// ```no_run

/// completed, rather than the entire buffer at once. Enter `LineWriter`. It /// does exactly that. /// <ins> /// Like [`BufWriter`], a `LineWriter`’s buffer will also be flushed when the /// `LineWriter` goes out of scope or when its internal buffer is full. /// </ins> /// [bufwriter]: struct.BufWriter.html /// /// If there's still a partial line in the buffer when the `LineWriter` is

/// /// The internal buffer is written out before returning the writer. /// <ins> // # Errors /// /// An `Err` will be returned if an error occurs while flushing the buffer. /// </ins> /// # Examples /// /// ```
Change:
talks about producing builds but not how to use them. i.e. do they need to packaged and installed someplace? Where is this? How do use multiple ones at the same time? etc.
So right now, the includes a little note about , including a link to about the linked toolchain feature. I'll take the opportunity to expand the note into its own section, though.
I've opened up to expand the rustup note into its own section.

Discussion:
guidelines as of yet, but basic rules like 4 spaces for indentation and no more than 99 characters in a single line should be kept in mind when writing code. <del> - `rustup toolchain link <name> build/<host-triple>/<stage>` - Use the custom compiler build via [rustup](https://github.com/rust-lang-nursery/rustup.rs#working-with-custom-toolchains-and-local-builds). </del> <ins> ### Using your local build If you use Rustup to manage your rust install, it has a feature called ["custom toolchains"][toolchain-link] that you can use to access your newly-built compiler without having to install it to your system or user PATH. If you've run `python x.py build`, then you can add your custom rustc to a new toolchain like this: [toolchain-link]: https://github.com/rust-lang-nursery/rustup.rs#working-with-custom-toolchains-and-local-builds ``` rustup toolchain link <name> build/<host-triple>/stage2 ``` Where `<host-triple>` is the build triple for the host (the triple of your computer, by default), and `<name>` is the name for your custom toolchain. (If you added `--stage 1` to your build command, the compiler will be in the `stage1` folder instead.) You'll only need to do this once - it will automatically point to the latest build you've done. Once this is set up, you can use your custom toolchain just like any other. For example, if you've named your toolchain `local`, running `cargo +local build` will compile a project with your custom rustc, setting `rustup override set local` will override the toolchain for your current directory, and `cargo +local doc` will use your custom rustc and rustdoc to generate docs. (If you do this with a `--stage 1` build, you'll need to build rustdoc specially, since it's not normally built in stage 1. `python x.py build --stage 1 src/libstd src/tools/rustdoc` will build rustdoc and libstd, which will allow rustdoc to be run with that toolchain.) </ins> ## Pull Requests
Change:
It currently gives two - one for outside and one for an unknown import. The latter should be silenced. e.g.,
I will work on this
On an related note, shouldn't there be a lint for . Maybe say "you can just use ."

Discussion:
if let Some(err) = self.finalize_import(import) { errors = true; <ins> if let SingleImport { source, ref result, .. } = import.subclass { if source.name == "self" { // Silence `unresolved import` error if E0429 is already emitted match result.value_ns.get() { Err(Determined) => continue, _ => {}, } } } </ins> // If the error is a single failed import then create a "fake" import // resolution for it so that later resolve stages won't complain. self.import_dummy_binding(import);

// except according to those terms. use std::fmt::self; //~ ERROR E0429 <del> //~^ ERROR E0432 </del> fn main () { }

mod a { mod b { <del> use self as A; //~ ERROR `self` imports are only allowed within a { } list //~^ ERROR unresolved import `self` [E0432] //~| no `self` in the root </del> <ins> use self as A; //~^ ERROR `self` imports are only allowed within a { } list </ins> use super as B; //~^ ERROR unresolved import `super` [E0432] //~| no `super` in the root

use foo::self; //~ ERROR unresolved import `foo::self` //~^ ERROR `self` imports are only allowed within a { } list <ins> use std::mem::self; //~^ ERROR `self` imports are only allowed within a { } list </ins> fn main() {}
Change:
Steps to reproduce: Alternative steps to reproduce that will provides a suitable compiler: On OS X, with LLVM assertions disabled (like in rustc builds in , which are the default in Servo’s ), rustc 1.20.0-nightly ( 2017-06-28) fails with: This problem does not occur with from rustup, which has LLVM assertions enabled. (But perhaps that’s not the only difference between the two kinds of builds?)
What’s ?
It’s also enabled in the "non-alt" build, so probably not relevant.
Have you tried building the project in the same disk partition where you've installed rustc, i.e. inside ?
Yes. With the second set of steps (and ), the error message looks like this:
Does show anything special?
not as far I can tell.
Okay... There are for dyld but I doubt if they are useful. The problem is that is not found, meaning is not expanded properly. I've checked does not* have an load command, meaning the is only supplied through . I don't think the alt-build's and normal build's Cargo has any difference though. Verify if is correct?
with and without in : Both contain:
Both contains directly inside ? (not )
Almost, the one has a different hash:
Huh, that's even stranger. The should be resolved correctly. But the alt- rustc linked using the libstd from the non-alt-build??
Well it sounds unlikely to me that “from the other build” is really what’s going on, I’d bet on incorrect hashing. How is the hexadecimal part of determined? What base values are being hashed?
IIRC rustc will just search for all , it doesn't recompute the hash. Would it work if you move out of , and then do a + ?
I first hit the issue before the "non-alt" build was downloaded.
I've tried to reproduce it myself and it seems plays a role in finding which is linked. I can make it link to the correctly hashed by: "Install" it sure does not contain , and includes it. It should work. Overriding without installing causes rustc not able to find .
What is "it" and what does "installing" mean?
Run after extracting the tarball (sorry was on mobile so did not check the exact instruction).
What does this do besides copying the files? Regardless, this is a regression, it only happens on OS X, and only with "alternate" builds…
It looks like the problem is presumably that and don't have the same hash. One fairly clear problem is that Servo for some reason doesn't download rust-std from alt by-default AFAICT; having some quick prints to the util script. That would lead to incompatibilities; this should be fixed.
I've filed which should fix this.
Good catch! This fixes the problem, thank you.

Discussion:
- env: IMAGE=dist-x86_64-linux DEPLOY_ALT=1 - env: > RUST_CHECK_TARGET=dist <del> RUST_CONFIGURE_ARGS="--enable-extended" </del> <ins> RUST_CONFIGURE_ARGS="--enable-extended --enable-profiler" </ins> SRC=. DEPLOY_ALT=1 RUSTC_RETRY_LINKER_ON_SEGFAULT=1

# "alternate" deployment, see .travis.yml for more info - MSYS_BITS: 64 <del> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-extended </del> <ins> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-extended --enable-profiler </ins> SCRIPT: python x.py dist DEPLOY_ALT: 1
Change:
This is to track the stabilization of , in .
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] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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:

Discussion:
# `iterator_for_each` <del> The tracking issue for this feature is: [#TBD] </del> <ins> The tracking issue for this feature is: [#42986] </ins> <del> [#TBD]: https://github.com/rust-lang/rust/issues/TBD </del> <ins> [#42986]: https://github.com/rust-lang/rust/issues/42986 </ins> ------------------------

///       .for_each(|(i, x)| println!("{}:{}", i, x)); /// ``` #[inline] <del> #[unstable(feature = "iterator_for_each", issue = "0")] </del> <ins> #[unstable(feature = "iterator_for_each", issue = "42986")] </ins> fn for_each<F>(self, mut f: F) where Self: Sized, F: FnMut(Self::Item), {
Change:
Stack trace: The here is a , and is : .
Reduced. It is just that the field of has no stability marker (compare with the source code of ). cc .

Discussion:
/// ``` #[derive(PartialEq, Eq, Debug)] #[stable(feature = "reverse_cmp_key", since = "1.19.0")] <del> pub struct Reverse<T>(pub T); </del> <ins> pub struct Reverse<T>(#[stable(feature = "reverse_cmp_key", since = "1.19.0")] pub T); </ins> #[stable(feature = "reverse_cmp_key", since = "1.19.0")] impl<T: PartialOrd> PartialOrd for Reverse<T> {