jiebi/CodeConvo huggingface dataset:
Code change:
} fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

Related discussion:
text: While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.
Code change:
} fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

Related discussion:
text: When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.
Code change:
} fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

Related discussion:
text: As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)
Code change:
#[rustc_doc_primitive = "f64"] #[doc(alias = "double")] <del> /// A 64-bit floating point type (specifically, the "binary64" type defined in IEEE 754-2008). </del> <ins> /// A 64-bit floating-point type (specifically, the "binary64" type defined in IEEE 754-2008). </ins> /// /// This type is very similar to [`prim@f32`], but has increased precision by using twice as many /// bits. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on double-precision

Related discussion:
text: Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .
Code change:
/// the hashmap because certain items (traits and types) need to have their mappings for trait /// implementations filled out before they're inserted. fn item(&mut self, item: clean::Item) -> Result<(), Error> { <del> let local_blanket_impl = match item.def_id { clean::ItemId::Blanket { impl_id, .. } => impl_id.is_local(), clean::ItemId::Auto { .. } | clean::ItemId::DefId(_) | clean::ItemId::Primitive(_, _) => false, }; </del> // Flatten items that recursively store other items <del> // FIXME(CraftSpider): We skip children of local blanket implementations, as we'll have //     already seen the actual generic impl, and the generated ones don't need documenting. //     This is necessary due to the visibility, return type, and self arg of the generated //     impls not quite matching, and will no longer be necessary when the mismatch is fixed. if !local_blanket_impl { item.kind.inner_items().for_each(|i| self.item(i.clone()).unwrap()); } </del> <ins> item.kind.inner_items().for_each(|i| self.item(i.clone()).unwrap()); </ins> let id = item.def_id; if let Some(mut new_item) = self.convert_item(item) {

Related discussion:
text: Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):
Code change:
//      '👎 Deprecated since 1.0.0: deprecated' // @has issue_32374/struct.U.html '//*[@class="stab unstable"]'  //      '🔬 This is a nightly-only experimental API. (test #32374)' <del> // @has issue_32374/struct.U.html '//details'  //      '🔬 This is a nightly-only experimental API. (test #32374)' // @has issue_32374/struct.U.html '//summary'  //      '🔬 This is a nightly-only experimental API. (test #32374)' // @has issue_32374/struct.U.html '//details/p'  //      'unstable' </del> #[rustc_deprecated(since = "1.0.0", reason = "deprecated")] #[unstable(feature = "test", issue = "32374", reason = "unstable")] pub struct U;

Related discussion:
text: Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.
Code change:
//      '👎 Deprecated since 1.0.0: deprecated' // @has issue_32374/struct.U.html '//*[@class="stab unstable"]'  //      '🔬 This is a nightly-only experimental API. (test #32374)' <del> // @has issue_32374/struct.U.html '//details'  //      '🔬 This is a nightly-only experimental API. (test #32374)' // @has issue_32374/struct.U.html '//summary'  //      '🔬 This is a nightly-only experimental API. (test #32374)' // @has issue_32374/struct.U.html '//details/p'  //      'unstable' </del> #[rustc_deprecated(since = "1.0.0", reason = "deprecated")] #[unstable(feature = "test", issue = "32374", reason = "unstable")] pub struct U;

Related discussion:
text: Making them less visually prominent, such as by reducing their contrast and making the warning just plain unstyled text, perhaps in the same place that stability information goes (though see for discussion on that), would help out a lot.
I would prefer this option. One benefit of showing the unstable APIs is that it invites people to test them, so having an opt-in for the curious would be good.
I would prefer an opt-out to an opt-in, that is, keep what we do today, but provide the ability to hide it if desired.
After spending some more time browsing the docs with an eye out for things that are visually distracting or attention grabbing, another option would be to just use a less attention grabbing way to denote unstable and deprecated items. Right now, they each use an extra, brightly colored box that makes them take up more visual space on the screen than stable items. On module index pages, they are actually made less prominent; they are sorted to the bottom, and made lower contrast with the background. This helps make them less attention catching, rather than more attention catching. But when browsing the methods provided on a struct or trait, they come with the big bright warning boxes that make them stand out more. I think I would still have a slight preference for having them hidden by default and just making the nightly docs easier to discover, such as having a version chooser in the header or sidebar, because of the issue mentioned in about docs of unstable items potentially being out of date. But making them less visually prominent rather than more visually prominent would help a lot.
I agree that the better way to solve this is by (perhaps) reducing the prominence of the "nightly-only" box. I don't think we should hide unstable items in the stable rustdoc generated at If someone is reading code that uses an unstable method, there's a good chance they will go to look it up in the stable docs. It would be a frustrating and confusing experience to not be able to find the method in the docs. It's a much better experience to find the method and be informed it's nightly-only / unstable. We probably don't want to reduce the prominence too much, though. If someone's looking for a method to call, it's pretty important that they notice when it's nightly-only. If they're working on a stable crate, that may mean they're not able to use the method at all.
Candidate PR at
Code change:
let external_paths = ctxt.external_paths.borrow_mut().take(); *analysis.external_paths.borrow_mut() = external_paths; let map = ctxt.external_typarams.borrow_mut().take(); *analysis.external_typarams.borrow_mut() = map; let map = ctxt.inlined.borrow_mut().take(); *analysis.inlined.borrow_mut() = map; analysis.deref_trait_did = ctxt.deref_trait_did.get(); <del> (krate, analysis) }), &sess) </del> <ins> Some((krate, analysis)) }), &sess); krate_and_analysis.unwrap() </ins> }

Related discussion:
text: Any of the following uses of cause an ICE in , but not in : Use of in a local is fine; these all simply report the error without an ICE.
I believe this may be a regression caused by . Working on a fix. Edit: Maybe not, actually. Either way I'm looking into it.
Code change:
<ins> // Copyright 2014 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. use std::io; use std::vec; pub struct Container<'a> { reader: &'a mut Reader //~ ERROR explicit lifetime bound required } impl<'a> Container<'a> { pub fn wrap<'s>(reader: &'s mut Reader) -> Container<'s> { Container { reader: reader } } pub fn read_to(&mut self, vec: &mut [u8]) { self.reader.read(vec); } } pub fn for_stdin<'a>() -> Container<'a> { let mut r = io::stdin(); Container::wrap(&mut r as &mut Reader) } fn main() { let mut c = for_stdin(); let mut v = vec::Vec::from_elem(10, 0u8); c.read_to(v.as_mut_slice()); } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code change:
<ins> // Copyright 2014 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. use std::io; use std::vec; pub struct Container<'a> { reader: &'a mut Reader //~ ERROR explicit lifetime bound required } impl<'a> Container<'a> { pub fn wrap<'s>(reader: &'s mut Reader) -> Container<'s> { Container { reader: reader } } pub fn read_to(&mut self, vec: &mut [u8]) { self.reader.read(vec); } } pub fn for_stdin<'a>() -> Container<'a> { let mut r = io::stdin(); Container::wrap(&mut r as &mut Reader) } fn main() { let mut c = for_stdin(); let mut v = vec::Vec::from_elem(10, 0u8); c.read_to(v.as_mut_slice()); } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code change:
<ins> // Copyright 2014 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. use std::io; use std::vec; pub struct Container<'a> { reader: &'a mut Reader //~ ERROR explicit lifetime bound required } impl<'a> Container<'a> { pub fn wrap<'s>(reader: &'s mut Reader) -> Container<'s> { Container { reader: reader } } pub fn read_to(&mut self, vec: &mut [u8]) { self.reader.read(vec); } } pub fn for_stdin<'a>() -> Container<'a> { let mut r = io::stdin(); Container::wrap(&mut r as &mut Reader) } fn main() { let mut c = for_stdin(); let mut v = vec::Vec::from_elem(10, 0u8); c.read_to(v.as_mut_slice()); } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code change:
<ins> // Copyright 2014 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. use std::io; use std::vec; pub struct Container<'a> { reader: &'a mut Reader //~ ERROR explicit lifetime bound required } impl<'a> Container<'a> { pub fn wrap<'s>(reader: &'s mut Reader) -> Container<'s> { Container { reader: reader } } pub fn read_to(&mut self, vec: &mut [u8]) { self.reader.read(vec); } } pub fn for_stdin<'a>() -> Container<'a> { let mut r = io::stdin(); Container::wrap(&mut r as &mut Reader) } fn main() { let mut c = for_stdin(); let mut v = vec::Vec::from_elem(10, 0u8); c.read_to(v.as_mut_slice()); } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
fn main() { let _x = "test" as &::std::any::Any; //~^ ERROR the trait `core::kinds::Sized` is not implemented for the type `str` <del> //~^^ NOTE the trait `core::kinds::Sized` must be implemented for the cast to the object type </del> <ins> //~^^ ERROR the trait `core::kinds::Sized` is not implemented for the type `str` </ins> }

Related discussion:
text: cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.
Code change:
<del> Subproject commit 8485d40a3264b15b92d391e99cb3d1abf8f25025 </del> <ins> Subproject commit 23549a8c362a403026432f65a6cb398cb10d44b7 </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Code change:
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() {}

Related discussion:
text: 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 ."
Code change:
/// println!("{:?}", Foo(vec![10, 11])); /// ``` #[stable(feature = "debug_builders", since = "1.2.0")] <del> #[inline] </del> pub fn debug_list<'b>(&'b mut self) -> DebugList<'b, 'a> { builders::debug_list_new(self) }

Related discussion:
text: After discussing it on the forums I bit I decided to look into what the optimizer spends time on, and inlining seems to be a significant part of it. There seems to be a lot of room for improvement here. Tested by compiling syntex in rustc-benchmarks (though the inlining time seem quite significant in other crates as well.). I counted which functions were inlined the most, and and to a lesser extent , which are when automatically deriving , and which simply wrap two other functions inside fmt::builder show up a lot. Maybe derive(debug) could output the wrapped functions instead, or the equivalent code, so llvm doesn't have to spend time inlining them (unless this causes problems for debug info). is also inlined a lot, and also plays a role in derive(Debug). Maybe something could be done about that one as well, as it's that creates a struct but doesn't do anything else. <details<summaryOutput from time-llvm-passes</summaryUsing in the syntex-0.42.2 directory in rustc-benchmarks. It's a bit hard to say which crate is which, as the output from llvm and cargo isn't synced, though these are the bottom three (excluding the benchmark dummy) in reverse order: </details<details<summaryMost inlined functions: </summaryRunning , and filtering the output using this: (Yeah it's a bit of a monstrosity, and takes a long time, maybe I could look into making some tool analyze this if it turns out to be useful.)
Code change:
/// println!("{:?}", Foo(vec![10, 11])); /// ``` #[stable(feature = "debug_builders", since = "1.2.0")] <del> #[inline] </del> pub fn debug_list<'b>(&'b mut self) -> DebugList<'b, 'a> { builders::debug_list_new(self) }

Related discussion:
text: gives: <pre1865 ZN4core3ptr13dropinplace17hffb7ed55089717f8E inlined into 917 ZN50Tascore..convert..FromTGT$4from17h99c56b7d2123957eE inlined into <b677 ZN4core3fmt9Arguments6newv117h0a32116e8ade096aE inlined into</b549 ZN4core3ptr13dropinplace17h8905708a4bea3261E inlined into <b517 ZN4core3fmt9Formatter11debugtuple17h312acfb009988478E inlined into</b484 ZN50Tascore..convert..FromTGT$4from17hf6536c6dc214691bE inlined into 438 ZN5alloc9allocator6Layout4size17h278602cb6317171dE inlined into 402 ZN63alloc..allocator..LayoutasGT$5clone17hba86f6db001903cdE inlined into 381 ZN61u20u20GT$7dealloc17h3db9762b4fdfd21eE inlined into 344 ZN5alloc4heap15exchangemalloc17he9800f033a6330e4E inlined into 341 ZN4core3ptr13dropinplace17hb5325e51b98a161aE inlined into ... <b82 ZN4core3fmt9Formatter12debug_struct17h5cfb920e90696799E inlined into</b... </pre</details<details<summaryrustc --version</summary</details
We should just drop the from those functions - debug printing is something we want to be optimizing on code size/compile time rather than perf.
Yup, that's a good point. EDIT: Actually since they're just generic over lifetimes it looks like that's not an issue.