jiebi/CodeConvo huggingface dataset:
Code change:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

Related discussion:
text: let module = self.new_module(parent_link, Some(def), true, is_public); self.try_define(new_parent, name, TypeNS, (module, DUMMY_SP)); } <del> Def::AssociatedTy(..) => { </del> <ins> Def::TyAlias(..) | Def::AssociatedTy(..) => { </ins> debug!("(building reduced graph for external crate) building type {}", final_ident); self.try_define(new_parent, name, TypeNS, (def, DUMMY_SP, modifiers));
Code change:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

Related discussion:
text: target_module: Module<'b>, directive: &'b ImportDirective) -> ResolveResult<()> { <ins> if let Some(Def::Trait(_)) = target_module.def { self.resolver.session.span_err(directive.span, "items in traits are not importable."); } </ins> if module_.def_id() == target_module.def_id() { // This means we are trying to glob import a module into itself, and it is a no-go let msg = "Cannot glob-import a module into itself.".into();
Code change:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

Related discussion:
text: <ins> // Copyright 2016 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. type Alias = (); use Alias::*; //~ ERROR Not a module use std::io::Result::*; //~ ERROR Not a module trait T {} use T::*; //~ ERROR items in traits are not importable fn main() {} </ins>
Code change:
For example, that the struct being dropped has not been deallocated when is called (it's implied by the existence of and Rust's general reluctance to dangle pointers, but still...), and that the struct members are recursively dropped after finishes, and what happens if panics.

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] pub trait Drop { /// A method called when the value goes out of scope. <ins> /// /// When this method has been called, `self` has not yet been deallocated. /// If it were, `self` would be a dangling reference. /// /// After this function is over, the memory of `self` will be deallocated. /// /// # Panics /// /// Given that a `panic!` will call `drop()` as it unwinds, any `panic!` in /// a `drop()` implementation will likely abort. </ins> #[stable(feature = "rust1", since = "1.0.0")] fn drop(&mut self); }
Code change:
It would be nice, if the would mention that the process is detached (and not joined) by default, when a object goes out of scope. Not having a impl is too subtile IMO.
Part of
I'd be happy to take this on. :smile:
Please do! :) On Jan 30, 2016, 11:59 -0500, Dirk , wrote:

Related discussion:
text: /// /// assert!(ecode.success()); /// ``` <ins> /// /// # Note /// /// Take note that there is no implementation of /// [`Drop`](../../core/ops/trait.Drop.html) for child processes, so if you /// do not ensure the `Child` has exited then it will continue to run, even /// after the `Child` handle to the child process has gone out of scope. /// /// Calling `wait` (or other functions that wrap around it) will make the /// parent process wait until the child has actually exited before continuing. </ins> #[stable(feature = "process", since = "1.0.0")] pub struct Child { handle: imp::Process,
Code change:
Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .

Related discussion:
text: use something::Foo; // error: unresolved import `something::Foo`. ``` <del> Please verify you didn't misspell the import name or the import does exist in the module from where you tried to import it. Example: </del> <ins> Paths in `use` statements are relative to the crate root. To import items relative to the current and parent modules, use the `self::` and `super::` prefixes, respectively. Also verify that you didn't misspell the import name and that the import exists in the module from where you tried to import it. Example: </ins> ```ignore <del> use something::Foo; // ok! </del> <ins> use self::something::Foo; // ok! </ins> mod something { pub struct Foo;
Code change:
Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .

Related discussion:
text: ``` Or, if you tried to use a module from an external crate, you may have missed <del> the `extern crate` declaration: </del> <ins> the `extern crate` declaration (which is usually placed in the crate root): </ins> ```ignore extern crate homura; // Required to use the `homura` crate
Code change:
rustdoc source links end in as can be seen here at the moment (the [src] link) Source link is: (Which is a dead link) Also reproduced locally using rustc 1.9.0-nightly ( 2016-03-07)

Related discussion:
text: // has anchors for the line numbers that we're linking to. } else if self.item.def_id.is_local() { self.cx.local_sources.get(&PathBuf::from(&self.item.source.filename)).map(|path| { <del> format!("{root}src/{krate}/{path}.html#{href}", </del> <ins> format!("{root}src/{krate}/{path}#{href}", </ins> root = self.cx.root_path, krate = self.cx.layout.krate, path = path,
Code change:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

Related discussion:
text: } } <ins> fn increment_outstanding_references(&mut self, is_public: bool) { self.outstanding_references += 1; if is_public { self.pub_outstanding_references += 1; } } fn decrement_outstanding_references(&mut self, is_public: bool) { let decrement_references = |count: &mut _| { assert!(*count > 0); *count -= 1; }; decrement_references(&mut self.outstanding_references); if is_public { decrement_references(&mut self.pub_outstanding_references); } } </ins> fn report_conflicts<F: FnMut(&NameBinding, &NameBinding)>(&self, mut report: F) { let binding = match self.binding { Some(binding) => binding,
Code change:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

Related discussion:
text: } pub fn increment_outstanding_references_for(&self, name: Name, ns: Namespace, is_public: bool) { <del> let mut resolutions = self.resolutions.borrow_mut(); let resolution = resolutions.entry((name, ns)).or_insert_with(Default::default); resolution.outstanding_references += 1; if is_public { resolution.pub_outstanding_references += 1; } } fn decrement_outstanding_references_for(&self, name: Name, ns: Namespace, is_public: bool) { let decrement_references = |count: &mut _| { assert!(*count > 0); *count -= 1; }; self.update_resolution(name, ns, |resolution| { decrement_references(&mut resolution.outstanding_references); if is_public { decrement_references(&mut resolution.pub_outstanding_references); } }) </del> <ins> self.resolutions.borrow_mut().entry((name, ns)).or_insert_with(Default::default) .increment_outstanding_references(is_public); </ins> } // Use `update` to mutate the resolution for the name.
Code change:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

Related discussion:
text: // Temporarily count the directive as determined so that the resolution fails // (as opposed to being indeterminate) when it can only be defined by the directive. if !determined { <del> module_.decrement_outstanding_references_for(target, ns, directive.is_public) </del> <ins> module_.resolutions.borrow_mut().get_mut(&(target, ns)).unwrap() .decrement_outstanding_references(directive.is_public); </ins> } let result = self.resolver.resolve_name_in_module(target_module, source, ns, false, true);
Code change:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

Related discussion:
text: self.report_conflict(target, ns, &directive.import(binding, None), old_binding); } } <del> module_.decrement_outstanding_references_for(target, ns, directive.is_public); </del> <ins> module_.update_resolution(target, ns, |resolution| { resolution.decrement_outstanding_references(directive.is_public); }) </ins> } match (&value_result, &type_result) {
Code change:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

Related discussion:
text: <ins> // Copyright 2016 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. #![feature(rustc_attrs)] #![allow(warnings)] mod foo { pub fn bar() {} } pub use foo::*; use b::bar; mod foobar { use super::*; } mod a { pub mod bar {} } mod b { pub use a::bar; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>
Code change:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

Related discussion:
text: ret }); <del> // Needs to go *after* expansion to be able to check the results // of macro expansion.  This runs before #[cfg] to try to catch as // much as possible (e.g. help the programmer avoid platform // specific differences) time(time_passes, "complete gated feature checking 1", || { sess.track_errors(|| { let features = syntax::feature_gate::check_crate(sess.codemap(), &sess.parse_sess.span_diagnostic, &krate, &attributes, sess.opts.unstable_features); *sess.features.borrow_mut() = features; }) })?; </del> // JBC: make CFG processing part of expansion to avoid this problem: // strip again, in case expansion added anything with a #[cfg].
Code change:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

Related discussion:
text: "checking for inline asm in case the target doesn't support it", || no_asm::check_crate(sess, &krate)); <del> // One final feature gating of the true AST that gets compiled // later, to make sure we've got everything (e.g. configuration // can insert new attributes via `cfg_attr`) time(time_passes, "complete gated feature checking 2", || { </del> <ins> // Needs to go *after* expansion to be able to check the results of macro expansion. time(time_passes, "complete gated feature checking", || { </ins> sess.track_errors(|| { let features = syntax::feature_gate::check_crate(sess.codemap(), &sess.parse_sess.span_diagnostic,
Code change:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

Related discussion:
text: // When we enter a module, record it, for the sake of `module!` pub fn expand_item(it: P<ast::Item>, fld: &mut MacroExpander) -> SmallVector<P<ast::Item>> { <del> let it = expand_item_multi_modifier(Annotatable::Item(it), fld); expand_annotatable(it, fld) </del> <ins> expand_annotatable(Annotatable::Item(it), fld) </ins> .into_iter().map(|i| i.expect_item()).collect() }
Code change:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

Related discussion:
text: <ins> // Copyright 2016 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. #![feature(rustc_attrs)] macro_rules! mac { {} => { #[cfg(attr)] mod m { #[lang_item] fn f() {} } } } mac! {} #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>
Code change:
The Unix implementation of in boils down to: The branch of the conditional doesn't properly handle the case where fails. For comparison's sake, the Windows implementation says:
Oh dear, seems bad! Out of curiosity, was this discovered from reading or from a bug? We could consider a backport to beta if that's necessary
This was discovered when reading through to write a custom memory allocator for Firefox. I suspect it's hard to make it trigger due to overcommit policies and the general lack of usage of over-aligned types.

Related discussion:
text: libc::realloc(ptr as *mut libc::c_void, size as libc::size_t) as *mut u8 } else { let new_ptr = allocate(size, align); <del> ptr::copy(ptr, new_ptr, cmp::min(size, old_size)); deallocate(ptr, old_size, align); </del> <ins> if !new_ptr.is_null() { ptr::copy(ptr, new_ptr, cmp::min(size, old_size)); deallocate(ptr, old_size, align); } </ins> new_ptr } }
Code change:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .

Related discussion:
text: glob_importers: RefCell<Vec<(Module<'a>, &'a ImportDirective<'a>)>>, globs: RefCell<Vec<&'a ImportDirective<'a>>>, <ins> // Used to memoize the traits in this module for faster searches through all traits in scope. traits: RefCell<Option<Box<[&'a NameBinding<'a>]>>>, </ins> // Whether this module is populated. If not populated, any attempt to // access the children must be preceded with a // `populate_module_if_necessary` call.