jiebi/CodeConvo huggingface dataset:
Change:
When a shared reference is assign, the gluedrop function is called with the old value before the gluetake function is called with the newvalue. With an assignment like "self.o = self.o;" the generated program will core. Of course, it's a silly example. All other examples I tried make a gluetake before calling the assignment (for example if you call a function with the argument "self.o" which will be then assigned) so you should never have this case in a real program. Maybe it doesn't need to be fixed as it shouldn't happen with a real program.
A simpler example: That segfaults for me. This should definitely be fixed!
Hm. At some point we had a test for this because I was quite careful to make this work correctly. Wonder when it broke.
Still segfaults as of
Not 0.6
Still segfaults as of . Nominating for milestone 5, production-ready
accepted for production-ready milestone
Still crashing
Still crashing with
accepted for P-high
Working on this
This no longer reproduces (with NIko's test case). I also tried with a managed pointer because apparently glue take/drop is only used for ref counting now and could not repro that way either. I tried to create a testcase as described in the first comment, but TBH I'm not really sure what was required. I tried a few things nothing crashed. I also examined the llvm ir and the 'problem' is that we never create these drop before take patterns. Anyone got an idea for how else this bug could be repro'ed (I really don't understand the glue stuff, so I might be missing something obvious)? Otherwise I suggest the bug should be closed.
I'm not sure if we have a test for this already. Perhaps there's one that was marked as ignored.
With a test case checked in, it looks like this can be closed (unless there's another subtler bug going on here).
I made a big effort to get this right as part of -- and totally forgot to write tests!

Discussion:
<ins> // Copyright 2012-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. // Ensure assigning an owned or managed variable to itself works. In particular, // that we do not glue_drop before we glue_take (#3290). use std::rc::Rc; pub fn main() { let mut x = ~3; x = x; assert!(*x == 3); let mut x = Rc::new(3); x = x; assert!(*x.borrow() == 3); } </ins>
Change:
I am learning rust and reading the book for the first time The section mentions a "Next Project" at the very end We can add a link to that project ?
It's referring to the next project showed in the book (so next section if I remember well). If confirms, this issue can be closed.
Actually, this sentence is vestigial from when we had the Dining Philosophers chapter. I would actually prefer to remove this sentence. Want to submit another PR? :D
absolutely :-) on it
was interested in looking at the old . pasted here for future people was removed in
sent PR

Discussion:
# Complete! <del> At this point, you have successfully built the Guessing Game! Congratulations! </del> <ins> This project showed you a lot: `let`, `match`, methods, associated functions, using external crates, and more. </ins> <del> This first project showed you a lot: `let`, `match`, methods, associated functions, using external crates, and more. Our next project will show off even more. </del> <ins> At this point, you have successfully built the Guessing Game! Congratulations! </ins>
Change:
When I try to compile a simple program using the syntax crate on FreeBSD, it seems to be unable to find the library: I first got the error when trying to compile , but from the above test it seems clear that the issue is not in the crate itself. I'm currently running nightly-2016-04-13 (installed from the newly-avaliable multirust toolchain for FreeBSD). In case it's helpful to know, there does seem to be a in , but I'm not sure how to figure out why I'm unable to use it.
I'm seeing the same on host=armv7-unknown-linux-gnueabihf (installed via rustup). But I think this is expected because there is no in the .multirust directory. cc
Oh man, first off thanks for testing FreeBSD :). Second, thanks for the report! Third, gah this is a rustbuild bug. It turns out that the rust-std package is actually "all target libraries" in the sense that it's more than just libstd, it's every target library we have available for that platform. Consequently, rustbuild needs to package librustc target libs into the rust-std package if the target is configured as a host. cc seems surprising in the sense that "rust-std" is an odd name, but makes sense in terms of "that package contains all libraries for the target we have available".
Same problem in a RaspberryPi
I already mentioned the same problem happens on host=armv7-unknown-linux-gnueabihf :smile:. And there's a fix in . OT: Is that an RPi 1 or RPi 2? Because you are not supposed to use the armv7-unknown-linux-gnueabihf target with the RPi 1. I actually expect would crash in that case.
Sorry about that!. I am using RPi 2.
It's okay! We got a confirmation of the bug :+1:. Never mind what I said then. (I was wondering if there was a bug where armv7 toolchain gets installed on the RPi 1. I'm glad that's not the case!)

Discussion:
vec![self.rustc(stage)] } Source::DistStd { compiler } => { <del> vec![self.libtest(compiler)] </del> <ins> // We want to package up as many target libraries as possible // for the `rust-std` package, so if this is a host target we // depend on librustc and otherwise we just depend on libtest. if build.config.host.iter().any(|t| t == self.target) { vec![self.librustc(compiler)] } else { vec![self.libtest(compiler)] } </ins> } Source::Dist { stage } => {
Change:
Right now, if we have an anonymous item, we use a dummy ident for its field in the AST. This should really be an option, since for example, anonymous foreign mods will soon be allowed.
Not critical for 0.6, de-milestoning
This seems to be obsolete, since we don't have anonymous foreign mods anymore.

Discussion:
pub id: NodeId, } <del> //  FIXME (#3300): Should allow items to be anonymous. Right now //  we just use dummy names for anon items. </del> /// An item /// /// The name might be a dummy name in case of anonymous items

} } <del> /* FIXME (#3300): Should allow items to be anonymous. Right now we just use dummy names for anon items. */ </del> /// An item /// /// The name might be a dummy name in case of anonymous items
Change:
I would expect this to work, and print '1': . Instead the compiler informs me: Perhaps should implement ?
Sounds like a good idea to me!

Discussion:
/// all standard arithmetic operations on the underlying value are /// intended to have wrapping semantics. #[stable(feature = "rust1", since = "1.0.0")] <del> #[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Copy, Debug, Default)] </del> <ins> #[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Copy, Default, Hash)] </ins> pub struct Wrapping<T>(#[stable(feature = "rust1", since = "1.0.0")] pub T); <ins> #[stable(feature = "rust1", since = "1.0.0")] impl<T: fmt::Debug> fmt::Debug for Wrapping<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { self.0.fmt(f) } } #[stable(feature = "wrapping_display", since = "1.10.0")] impl<T: fmt::Display> fmt::Display for Wrapping<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { self.0.fmt(f) } } </ins> mod wrapping; // All these modules are technically private and only exposed for libcoretest:
Change:
Gives this example code to show the problem. This example does not return E0102, but E0282.
cc

Discussion:
"##, E0102: r##" <del> You hit this error because the compiler lacks information to determine a type for this variable. Erroneous code example: </del> <ins> You hit this error because the compiler lacks the information to determine the type of this variable. Erroneous code example: </ins> ```compile_fail <del> fn demo(devil: fn () -> !) { let x: &_ = devil(); // error: cannot determine a type for this local variable } fn oh_no() -> ! { panic!("the devil is in the details") } </del> fn main() { <del> demo(oh_no); </del> <ins> // could be an array of anything let x = []; // error: cannot determine a type for this local variable </ins> } ``` To solve this situation, constrain the type of the variable. Examples: <del> ```no_run </del> <ins> ``` </ins> #![allow(unused_variables)] <del> fn some_func(x: &u32) { // some code } fn demo(devil: fn () -> !) { let x: &u32 = devil(); // Here we defined the type at the variable creation let x: &_ = devil(); some_func(x); // Here, the type is determined by the function argument type } fn oh_no() -> ! { panic!("the devil is in the details") } </del> fn main() { <del> demo(oh_no); </del> <ins> let x: [u8; 0] = []; </ins> } ``` "##,
Change:
ARC is beginning to infect more and more types, and they each must have a clone method, but there is no trait to implement.
related
Along with this, we should provide a default implementation of Clonable for all copyable types.
Closing this now that has been implemented. There are no doubt some types left that should have a implementation, but they can be dealt with on a case-by-case basis.

Discussion:
"itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", "regex 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "walkdir 2.2.5 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

<del> Subproject commit 5afdf8b78507ddf015d192858aef56e72c17de16 </del> <ins> Subproject commit b1d0343749bdc87e5cbbe7f1aeaa9d2a2c9dbc5b </ins>
Change:
Running on the following code: The output is: I would expect a line containing information about the imports inserted by the compiler, namely and . This used to work in the past.
cc
cc I wonder if one of the changes to name resolution could have caused this? I can't really imagine how, but it seems the most likely candidate.
This was caused by , which (correctly) changed the span of the path in a glob import to not include the suffix. The span change caused  to be so that the call to on the following line always returned true.
Unrelated to this issue, but we currently only dump glob-imported names that end up getting used. would you prefer we dump all glob imported names, even if they are not used?
Thanks ! The intended behviour is just to have the used names, i.e., the list of names one would use if you wanted to replace the glob import with a list import.
Ah, that makes sense. I was thinking more along the lines of refactoring away a needless qualification or moving a path from one module to another, in which we would want to know about unused names as well.
After the changes, I still can reproduce the issue :disappointed:
the changes haven't made it into the nighties yet (the current nightly is still 2016-04-28). If you can reproduce on a more up-to-date local build, could you include the and the emitted json?
Oops... Sorry, I thought the changes were already in nightly. My bad.
No problem!

Discussion:
} let sub_span = self.span <del> .sub_span_of_token(path.span, token::BinOp(token::Star)); if !self.span.filter_generated(sub_span, path.span) { </del> <ins> .sub_span_of_token(item.span, token::BinOp(token::Star)); if !self.span.filter_generated(sub_span, item.span) { </ins> self.dumper.use_glob(UseGlobData { span: sub_span.expect("No span found for use glob"), id: item.id,
Change:
Right now is predominately used to conditionally compile code for differing C libraries like msvc, glibc, musl, etc. On ARM, however, there are two glibc annotations, "gnueabi" and "gneuabihf". This then also extends to musl with "musleabi" and "musleabihf". This seems unnecessarily complicated to say "conditionally compile this code when using musl", that is it should only require one annotation, not three. We could possibly change as I doubt anyone's using "gnueabihf" as a matcher, or we could add a new .
cc
The presence of absence of hard float should be denoted inside its own feature instead ( or something). I believe we already have (or plans for) a few such switches already.
Could we use for choosing between static vs dynamic or release vs debug for the msvc CRT?
The toosl team discussed this issue at triage and the decision was to name as either gnu or musl instead of also gnueabi/musleabi. I'll send a PR shortly
There should probably also be a good way to distinguish between statically linked musl and dynamically linked musl targets.

Discussion:
data_layout: "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64".to_string(), arch: "arm".to_string(), target_os: "linux".to_string(), <del> target_env: "gnueabi".to_string(), </del> <ins> target_env: "gnu".to_string(), </ins> target_vendor: "unknown".to_string(), options: TargetOptions {

data_layout: "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64".to_string(), arch: "arm".to_string(), target_os: "linux".to_string(), <del> target_env: "gnueabihf".to_string(), </del> <ins> target_env: "gnu".to_string(), </ins> target_vendor: "unknown".to_string(), options: TargetOptions {
Change:
Discussion of with the lang team led to inspection of the documentation for and () just says "returns the size of a type in bytes." Understanding what this means (and deciding whether it is true or not) depends on how one interprets the word "size" in that sentence. () is worse. Why? Because it adds the additional paragraph: This is much more specific, but the specifics are wrong in terms of that the implementation does. The quoted text is describing the notion of "size" as . But Rust's implementation of ends up eventually calling out to LLVM's , which: At this point we cannot change the name nor the behavior of -- which is fine, since as I understand it, the behavior of basically matches that of in the C/C++ language family. But we should: the documentation for , to make it clear what its behavior is (for this, we might as well point out that it is behaving like "stride" in Swift's terms) should either fix the documentation for so it no longer outright lies, or replace that single intrinsic with a pair of intrinsics that are analogous to Swift's and . (With respect to , if we do introduce an analogous distinction, we will have to choose a name other than "size" for the quantity that is not forcibly rounded up to a multiple of the alignment. Maybe "length", "fill", or "utilization"...) Neither of the above items are incredibly high priority, since the docs are not currently lying (just vague), and is unstable. But it would probably be good to address at least one of the two, for these reasons: to avoid users making invalid inferences about 's behavior (and thus manually rounding up its results to each type's alignment), and to avoid some well-meaning Rust developer cut-and-pasting the docs over into .
I'd like to take this one if is alright with it.

Discussion:
/// The size of a type in bytes. /// <del> /// This is the exact number of bytes in memory taken up by a /// value of the given type. In other words, a memset of this size /// would *exactly* overwrite a value. When laid out in vectors /// and structures there may be additional padding between /// elements. </del> <ins> /// More specifically, this is the offset in bytes between successive /// items of the same type, including alignment padding. </ins> pub fn size_of<T>() -> usize; /// Moves a value to an uninitialized memory location.

/// Returns the size of a type in bytes. /// <ins> /// More specifically, this is the offset in bytes between successive /// items of the same type, including alignment padding. /// </ins> /// # Examples /// /// ```
Change:
I'm building Rust with , it fails at the miniz step:
This is due to , specifically . The problem is that --enable-ccache exports and it's ambiguous whether that's a file name with a space in it or two arguments.

Discussion:
export CCACHE_BASEDIR endif <del> FIND_COMPILER = $(word 1,$(1:ccache=)) </del> <ins> FIND_COMPILER = $(strip $(1:ccache=)) </ins> define CFG_MAKE_TOOLCHAIN # Prepend the tools with their prefix if cross compiling

endif endif <del> CFG_COMPILE_C_$(1) = '$$(CC_$(1))'  </del> <ins> CFG_COMPILE_C_$(1) = '$$(call FIND_COMPILER,$$(CC_$(1)))'  </ins> $$(CFLAGS)  $$(CFG_GCCISH_CFLAGS)  $$(CFG_GCCISH_CFLAGS_$(1)) 

$$(CFG_GCCISH_LINK_FLAGS_$(1))  $$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2)  $$(call CFG_INSTALL_NAME_$(1),$$(4)) <del> CFG_COMPILE_CXX_$(1) = '$$(CXX_$(1))'  </del> <ins> CFG_COMPILE_CXX_$(1) = '$$(call FIND_COMPILER,$$(CXX_$(1)))'  </ins> $$(CXXFLAGS)  $$(CFG_GCCISH_CFLAGS)  $$(CFG_GCCISH_CXXFLAGS) 

--host-rustcflags "$(RUSTC_FLAGS_$(3)) $$(CTEST_RUSTC_FLAGS) -L $$(RT_OUTPUT_DIR_$(3))"  --lldb-python-dir=$(CFG_LLDB_PYTHON_DIR)  --target-rustcflags "$(RUSTC_FLAGS_$(2)) $$(CTEST_RUSTC_FLAGS) -L $$(RT_OUTPUT_DIR_$(2))"  <del> --cc '$$(CC_$(2))'  --cxx '$$(CXX_$(2))'  </del> <ins> --cc '$$(call FIND_COMPILER,$$(CC_$(2)))'  --cxx '$$(call FIND_COMPILER,$$(CXX_$(2)))'  </ins> --cflags "$$(CFG_GCCISH_CFLAGS_$(2))"  --llvm-components "$$(LLVM_ALL_COMPONENTS_$(2))"  --llvm-cxxflags "$$(LLVM_CXXFLAGS_$(2))"
Change:
1.9.0-beta.1 panics when a constant index expression is out of bounds in a range expression. Compilation failure and exit (without a panic). 1.8.0 catches this properly without panicking: 1.9.0-beta.1 also catches the error but then immediately panics:
This was fixed. With Rust 1.12.1 and later, this is now a warning, with no panic:

Discussion:
<ins> // Copyright 2017 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. const A: [u32; 1] = [0]; fn test() { let range = A[1]..; } fn main() { } </ins>
Change:
Hi everyone, This code caused a ICE for me. The compiler said this. The bug doesn't appear in rust stable or beta, only in nightly. edit: used minimal example instead of my code.
Can you give a self-contained example that reproduces the bug? I can't reproduce this on playpen.
Sure:
A smaller example:
This issue has been fixed by , but no test was submitted.
cc me

Discussion:
} } } <del> } else if let Err(false) = self.resolve_path(pat_id, &path, 0, ValueNS) { resolve_error( self, path.span, ResolutionError::UnresolvedEnumVariantStructOrConst( &path.segments.last().unwrap().identifier.name.as_str()) ); </del> <ins> } else { if let Err(false) = self.resolve_path(pat_id, &path, 0, ValueNS) { // No error has been reported, so we need to do this ourselves. resolve_error( self, path.span, ResolutionError::UnresolvedEnumVariantStructOrConst( &path.segments.last().unwrap().identifier.name.as_str()) ); } </ins> self.record_def(pattern.id, err_path_resolution()); } visit::walk_path(self, path);
Change:
I don't know whether this was already reported. I get an ICE when running on (also the previous commit, didn't test others). An older version works fine:
cc has Callee in trace.
My guess is or needs to normalize the substitutions/.
Getting the same ICE with but also on while running examples (works fine on 1.8.0).
Just bisected this and got Surely it regressed during the trans refactoring, but as none of the intermediate commits is building it's not exactly sure which change is to blame though. Will help investigating further.
I would try to fix this, already did one-liner fix in according to , both and the minimal testcase in passed without ICE. Will prepare the PR later ;-) (EDIT: It's with stage1. Currently building stage2 and seeing if it can pass all tests. New to compiler writing and maintenance so kindly point out anything you feel like, thanks.)

Discussion:
let method_item = tcx.impl_or_trait_item(def_id); let trait_id = method_item.container().id(); let trait_ref = ty::Binder(substs.to_trait_ref(tcx, trait_id)); <ins> let trait_ref = infer::normalize_associated_type(tcx, &trait_ref); </ins> match common::fulfill_obligation(ccx, DUMMY_SP, trait_ref) { traits::VtableImpl(vtable_impl) => { let impl_did = vtable_impl.impl_def_id;

<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. use std::marker::PhantomData; struct TheType<T> { t: PhantomData<T> } pub trait TheTrait { type TheAssociatedType; } impl TheTrait for () { type TheAssociatedType = (); } pub trait Shape<P: TheTrait> { fn doit(&self) { } } impl<P: TheTrait> Shape<P> for TheType<P::TheAssociatedType> { } fn main() { let ball = TheType { t: PhantomData }; let handle: &Shape<()> = &ball; } </ins>
Change:
These methods allow one to obtain a mutable reference to the interior of these cells if you have a mutable reference to the cells themselves.
As stated in , I think that a better name for these methods would be .
This issue is now entering its final comment period for stabilization The libs team was unfortunately a little late on stabilizations this cycle, but we're thinking of probably doing a backport of stabilizations partway through the beta cycle. This API also follows existing conventions so should be an easy stabilization!
Looking through the naming convention again, it seems that is only used for conversions or functions that are not cheap or free, e.g. accessing elements of containers, slices, checking the poisoning state of a mutex and returning the element (with the exception of , which isn't stabilized yet). However, is often used for this kind of conversion, e.g. . I don't think fits here.
Ah yes I forgot to mention, but the libs team did indeed discuss the name and concluded that is the convention here. The prefix is used for containers such as vectors, maps, I/O wrappers, synchronization primitives, etc. The prefix is intended for conversions. Because these are "containers" and these methods aren't performing conversions, we concluded the appropriate name was
The libs team discussed this issue during triage yesterday and the decision was to stabilize. We realize that the FCP for this issue was pretty short, however, so please comment with any objections you might have! We're very willing to backport an un-stabilization for the few APIs we have this cycle.

Discussion:
pub fn as_unsafe_cell(&self) -> &UnsafeCell<T> { &self.value } <ins> /// Returns a mutable reference to the underlying data. /// /// This call borrows `Cell` mutably (at compile-time) which guarantees /// that we possess the only reference. #[inline] #[unstable(feature = "cell_get_mut", issue = "33444")] pub fn get_mut(&mut self) -> &mut T { unsafe { &mut *self.value.get() } } </ins> } #[stable(feature = "rust1", since = "1.0.0")]

pub unsafe fn as_unsafe_cell(&self) -> &UnsafeCell<T> { &self.value } <ins> /// Returns a mutable reference to the underlying data. /// /// This call borrows `RefCell` mutably (at compile-time) so there is no /// need for dynamic checks. #[inline] #[unstable(feature = "cell_get_mut", issue="33444")] pub fn get_mut(&mut self) -> &mut T { unsafe { &mut *self.value.get() } } </ins> } #[stable(feature = "rust1", since = "1.0.0")]