jiebi/CodeConvo huggingface dataset:
Change:
Reading over the Ownership section in TRPL and came across the example As a newbie, this was very confusing. I believe the situation could be explained by simply adding another line. I'm not sure if this is the best way to do this.
This sounds like a great fix to me, (although I would add the to the signature for clarity). PR welcome! :smile:
I've been waiting for input on my PR for several days. Still have no response. The ? didn't compile, and so I'm not sure what to change it to. I thought this section was ignored by the compile, but it doesn't seem that way.
How about:
Oh, sorry. I didn't even parse that there was a PR referring back to this issue :sweat_smile:
That's what the original is, I was very confused by that, and I was trying to update the docs to sufficiently explain the problem with just a short bit of code. The second bit of code was much better at explaining the problem to me, as the question mark implies that the return lifetime is ambiguous.
It's also the only place that this notation is used, which makes it confusing.
So what should I change it to? suggested
I think that's fine

Discussion:
fn get_str() -> &str; // ILLEGAL, no inputs fn frob(s: &str, t: &str) -> &str; // ILLEGAL, two inputs <ins> fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // Expanded: Output lifetime is unclear </ins> fn get_mut(&mut self) -> &mut T; // elided fn get_mut<'a>(&'a mut self) -> &'a mut T; // expanded
Change:
The following code: Produces this error: Putting parens around and doesn't fix it.
Also, it doesn't work too (Should?):

Discussion:
self.bump(); pat = PatStruct(enum_path, fields, etc); } <ins> token::DotDotDot => { let hi = self.last_span.hi; let start = self.mk_expr(lo, hi, ExprPath(None, enum_path)); self.eat(&token::DotDotDot); let end = if self.token.is_ident() || self.token.is_path() { let path = self.parse_path(LifetimeAndTypesWithColons); let hi = self.span.hi; self.mk_expr(lo, hi, ExprPath(None, path)) } else { self.parse_literal_maybe_minus() }; pat = PatRange(start, end); } </ins> _ => { let mut args: Vec<P<Pat>> = Vec::new(); match self.token {

<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 m::{START, END}; fn main() { match 42u32 { m::START...m::END => {}, 0u32...m::END => {}, m::START...59u32 => {}, _  => {}, } } mod m { pub const START: u32 = 4; pub const END:   u32 = 14; } </ins>
Change:
When trying to call a method on a raw pointer Rust compiler says there's no such method. It would be better to say that there is such method, but the pointer has to be explicitly dereferenced first. This is technically correct, but unexpected and help hint for this error suggests wrong solution. I've read this message as "yada yada no such method", so I went to check whether I've spelled the method correctly, whether I've put the method in the appropriate block, etc. — all completely irrelevant to this error. I'd find something like that more helpful:
, though. The best we could do here is to add some logic in trait suggestion mechanism to check whether traits for dereferenced values exist. Something along the lines of Too many help messages will overwhelm messages that actually matter, though.
Triage: no change
Triage: the error message has improved /
To suggest it would have to suggest , which is taking the suggestions a bit far. We could add a note though.

Discussion:
); } } <ins> if let ty::RawPtr(_) = &actual.sty { err.note("try using `<*const T>::as_ref()` to get a reference to the  type behind the pointer: https://doc.rust-lang.org/std/ primitive.pointer.html#method.as_ref"); } </ins> err } } else {

<ins> fn main() { let x = 8u8; let z: *const u8 = &x; println!("{}", z.to_string());  //~ ERROR E0599 } </ins>

<ins> error[E0599]: no method named `to_string` found for type `*const u8` in the current scope --> $DIR/issue-21596.rs:4:22 | LL |     println!("{}", z.to_string()); |                      ^^^^^^^^^ | = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref = note: the method `to_string` exists but the following trait bounds were not satisfied: `*const u8 : std::string::ToString` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>
Change:
Because of , a local shorthand to a static function, this code fails to compile. Moving the down below it will compile. Error message: rust version:
This is now fixed (At least as of 1.0.0).
I'll create a regression test for this

Discussion:
<ins> // Copyright 2015 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. struct Index; impl Index { fn new() -> Self { Index } } fn user() { let new = Index::new; fn inner() { let index = Index::new(); } let index2 = new(); } fn main() {} </ins>
Change:
Should float::fromstr do the following conversions? "NaN" -float::NaN "inf" -float::infinity "-inf" -float::neginfinity That'd match what float::to_str does (if my pull request is merged.) If this sounds good I'll chuck a patch in.
It will be very good when this will be fixed. There are some additional points to be considered: If I remember correctly, the floating point standard allows for both short ("inf") and long ("infinity") syntax. Are you aware of the other float formatting related issues? I think there used to be a floating point literal parsing problem in rustc for very large literals (not fitting into 32 bits) that is related (can't find the issue right now). Besides adding support for NaN and inf in fromstr/tostr, I personally think rust should define a literal syntax for these, i.e. the compiler should support them directly.
If this is standard behavior for converting from strings than I say go for it.
More things to check proper handling of +0.0 vs -0.0 vs 0.0 hexadecimal notation for the mantissa for the lossless exchange of values
The last one is discusses in . The real kicker would be if all this were supposed by the parser as literal syntax.
Fixed by

Discussion:
* '', or, equivalently, '.' (understood as 0) * '5.' * '.5', or, equivalently,  '0.5' <ins> * 'inf', '-inf', 'NaN' </ins> Leading and trailing whitespace are ignored.

where `n` is the floating-point number represented by `[num]`. "] fn from_str(num: str) -> option<float> { <ins> if num == "inf" { ret some(infinity); } else if num == "-inf" { ret some(neg_infinity); } else if num == "NaN" { ret some(NaN); } </ins> let mut pos = 0u;               //Current byte position in the string. //Used to walk the string in O(n). let len = str::len(num);        //Length of the string, in bytes.

assert from_str("-.5") == some(-0.5); assert from_str("-.5") == some(-0.5); assert from_str("-5") == some(-5.); <ins> assert from_str("-0") == some(-0.); assert from_str("0") == some(0.); assert from_str("inf") == some(infinity); assert from_str("-inf") == some(neg_infinity); // note: NaN != NaN, hence this slightly complex test alt from_str("NaN") { some(f) { assert is_NaN(f); } none { fail; } } </ins> assert from_str("") == none; assert from_str("x") == none;
Change:
If I generate the llasm for run- and run it through the in-tree version of llvm-as I get the following error: The .bc file works fine.
I get the same error if dissembled the .bc file with llvm-dis and assemble back.
Not sure why we're declaring a global pointer to ruststart anyway. Seems like we should be declaring the ruststart function.
I realized the global thing is not a pointer, just a function. Look closely, it lacks a trailing star. :) LLVM LLparser should be correct to reject this.
Fixxed!

Discussion:
fn trans_external_path(ccx: @crate_ctxt, did: ast::def_id, t: ty::t) -> ValueRef { let name = csearch::get_symbol(ccx.sess.cstore, did); <del> let llty = alt ty::get(t).struct { ty::ty_fn(_) { type_of_fn_from_ty(ccx, t) } _ { type_of(ccx, t) } </del> <ins> alt ty::get(t).struct { ty::ty_fn(_) { let llty = type_of_fn_from_ty(ccx, t); ret get_extern_fn(ccx.externs, ccx.llmod, name, lib::llvm::CCallConv, llty); } _ { let llty = type_of(ccx, t); ret get_extern_const(ccx.externs, ccx.llmod, name, llty); } </ins> }; <del> ret get_extern_const(ccx.externs, ccx.llmod, name, llty); </del> } fn normalize_for_monomorphization(tcx: ty::ctxt, ty: ty::t) -> option<ty::t> {

let crate_map = ccx.crate_map; let start_ty = T_fn([val_ty(rust_main), ccx.int_type, ccx.int_type, val_ty(crate_map)], ccx.int_type); <del> let start = str::as_c_str("rust_start", {|buf| llvm::LLVMAddGlobal(ccx.llmod, start_ty, buf) }); </del> <ins> let start = decl_cdecl_fn(ccx.llmod, "rust_start", start_ty); </ins> let args = [rust_main, llvm::LLVMGetParam(llfn, 0 as c_uint), llvm::LLVMGetParam(llfn, 1 as c_uint), crate_map]; let result = unsafe {
Change:
With set to 'deny' by default, every time nightly stabilizes a feature your crate uses then it will break. cc cc
What still needs to be done here?
looks like this is still here and working, so closing.

Discussion:
declare_lint! { pub UNUSED_FEATURES, <del> Deny, </del> <ins> Warn, </ins> "unused or unknown features found in crate-level #[feature] directives" }
Change:
This happens only after the recent LLVM upgrade. The culprit seems to be half of : Changing the call to copy only 8 bytes instead of 16 (to not touch the portion) removes the infinite loop. cc
One workaround would be to replace with but I'm not sure if that will cause a hit on performance.
I haven't fully analyzed this, but that changing the memcpy size helps is coincidental. That just breaks a memcpy optimization that is required for the problem to show up, because the memcpy sizes now differ. AFAICT for now, this is some problem with aliasing.
So looking through the relevant changes in LLVM, I noticed that the docs for have been refined. And now they clarify that using on the return value is only meant for like functions, i.e. functions that return "new" pointers, not previously accessible to the caller at all. We use it for functions returning unique pointers and functions that return through sret pointers. Seems bad. See Testing a patch now.
FWIW, removing from the no-opt IR for the given testcase does indeed fix the problem.
Nice find!
Fun fact, our suspicion that our usage of lifetime intrinsics was at fault for a bunch of failures might have been totally off. Different usage of lifetimes might just have killed different memcpy optimizations, hiding the real culprit lol I still need to fix them to allow for better optimization though :-/
So here's the minimal LLVM IR I have so far: Removing the attribute on on makes the problem go away, but having there doesn't seem wrong to me.
Pretty sure this is a bug in the memcpyopt pass that doesn't update the scoped alias data.

Discussion:
<del> Subproject commit 2d54c4f559b1acbfe1867950c3a25bfb2f76b693 </del> <ins> Subproject commit 32c27dda3ae2318b6897f00795009cd6f42ac4b3 </ins>

# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2015-02-02 </del> <ins> 2015-02-09 </ins>
Change:
This succeeds and shouldn't. In , is also calling . Might just have to add a 2...
And tests probably...

Discussion:
#[inline] fn exp(self) -> f32 { num::Float::exp(self) } #[inline] <del> fn exp2(self) -> f32 { num::Float::exp(self) } </del> <ins> fn exp2(self) -> f32 { num::Float::exp2(self) } </ins> #[inline] fn ln(self) -> f32 { num::Float::ln(self) } #[inline]

} #[test] <ins> fn test_exp() { assert_eq!(1.0, 0.0f32.exp()); assert_approx_eq!(2.718282, 1.0f32.exp()); assert_approx_eq!(148.413162, 5.0f32.exp()); let inf: f32 = Float::infinity(); let neg_inf: f32 = Float::neg_infinity(); let nan: f32 = Float::nan(); assert_eq!(inf, inf.exp()); assert_eq!(0.0, neg_inf.exp()); assert!(nan.exp().is_nan()); } #[test] fn test_exp2() { assert_eq!(32.0, 5.0f32.exp2()); assert_eq!(1.0, 0.0f32.exp2()); let inf: f32 = Float::infinity(); let neg_inf: f32 = Float::neg_infinity(); let nan: f32 = Float::nan(); assert_eq!(inf, inf.exp2()); assert_eq!(0.0, neg_inf.exp2()); assert!(nan.exp2().is_nan()); } #[test] </ins> fn test_asinh() { assert_eq!(0.0f32.asinh(), 0.0f32); assert_eq!((-0.0f32).asinh(), -0.0f32);

#[inline] fn exp(self) -> f64 { num::Float::exp(self) } #[inline] <del> fn exp2(self) -> f64 { num::Float::exp(self) } </del> <ins> fn exp2(self) -> f64 { num::Float::exp2(self) } </ins> #[inline] fn ln(self) -> f64 { num::Float::ln(self) } #[inline]

} #[test] <ins> fn test_exp() { assert_eq!(1.0, 0.0f64.exp()); assert_approx_eq!(2.718282, 1.0f64.exp()); assert_approx_eq!(148.413159, 5.0f64.exp()); let inf: f64 = Float::infinity(); let neg_inf: f64 = Float::neg_infinity(); let nan: f64 = Float::nan(); assert_eq!(inf, inf.exp()); assert_eq!(0.0, neg_inf.exp()); assert!(nan.exp().is_nan()); } #[test] fn test_exp2() { assert_eq!(32.0, 5.0f64.exp2()); assert_eq!(1.0, 0.0f64.exp2()); let inf: f64 = Float::infinity(); let neg_inf: f64 = Float::neg_infinity(); let nan: f64 = Float::nan(); assert_eq!(inf, inf.exp2()); assert_eq!(0.0, neg_inf.exp2()); assert!(nan.exp2().is_nan()); } #[test] </ins> fn test_asinh() { assert_eq!(0.0f64.asinh(), 0.0f64); assert_eq!((-0.0f64).asinh(), -0.0f64);
Change:
has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in 
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.

Discussion:
/// Constructs a floating point number by multiplying `x` by 2 raised to the /// power of `exp` #[inline] <del> fn ldexp(x: f32, exp: int) -> f32 { unsafe { cmath::ldexpf(x, exp as c_int) } </del> <ins> fn ldexp(self, exp: isize) -> f32 { unsafe { cmath::ldexpf(self, exp as c_int) } </ins> } /// Breaks the number into a normalized fraction and a base-2 exponent,

let f1: f32 = FromStrRadix::from_str_radix("1p-123", 16).unwrap(); let f2: f32 = FromStrRadix::from_str_radix("1p-111", 16).unwrap(); let f3: f32 = FromStrRadix::from_str_radix("1.Cp-12", 16).unwrap(); <del> assert_eq!(Float::ldexp(1f32, -123), f1); assert_eq!(Float::ldexp(1f32, -111), f2); </del> <ins> assert_eq!(1f32.ldexp(-123), f1); assert_eq!(1f32.ldexp(-111), f2); </ins> assert_eq!(Float::ldexp(1.75f32, -12), f3); assert_eq!(Float::ldexp(0f32, -123), 0f32);

fn to_radians(self) -> f64 { num::Float::to_radians(self) } #[inline] <del> fn ldexp(x: f64, exp: int) -> f64 { unsafe { cmath::ldexp(x, exp as c_int) } </del> <ins> fn ldexp(self, exp: isize) -> f64 { unsafe { cmath::ldexp(self, exp as c_int) } </ins> } /// Breaks the number into a normalized fraction and a base-2 exponent,

let f1: f64 = FromStrRadix::from_str_radix("1p-123", 16).unwrap(); let f2: f64 = FromStrRadix::from_str_radix("1p-111", 16).unwrap(); let f3: f64 = FromStrRadix::from_str_radix("1.Cp-12", 16).unwrap(); <del> assert_eq!(Float::ldexp(1f64, -123), f1); assert_eq!(Float::ldexp(1f64, -111), f2); </del> <ins> assert_eq!(1f64.ldexp(-123), f1); assert_eq!(1f64.ldexp(-111), f2); </ins> assert_eq!(Float::ldexp(1.75f64, -12), f3); assert_eq!(Float::ldexp(0f64, -123), 0f64);

/// ``` #[unstable(feature = "std_misc", reason = "pending integer conventions")] <del> fn ldexp(x: Self, exp: isize) -> Self; </del> <ins> fn ldexp(self, exp: isize) -> Self; </ins> /// Breaks the number into a normalized fraction and a base-2 exponent, /// satisfying: ///
Change:
I have no idea why this is happening.
Try . And can you provide a copy of ?
You already have a file which belongs to user . Since you’re compiling as a regular user now, can’t overwrite the file and therefore fails. You can circumvent the issue by removing the file manually as root (). I’ll try to get rid of the ICE in the mean time. EDIT: this is backtrace:
Thanks, that worked.

Discussion:
} // Produce final compile outputs. <ins> let copy_gracefully = |from: &Path, to: &Path| { if let Err(e) = fs::copy(from, to) { sess.err(&format!("could not copy {:?} to {:?}: {}", from, to, e)); } }; </ins> let copy_if_one_unit = |ext: &str, output_type: config::OutputType, keep_numbered: bool| { // Three cases: if sess.opts.cg.codegen_units == 1 { // 1) Only one codegen unit.  In this case it's no difficulty //    to copy `foo.0.x` to `foo.x`. <del> fs::copy(&crate_output.with_extension(ext), &crate_output.path(output_type)).unwrap(); </del> <ins> copy_gracefully(&crate_output.with_extension(ext), &crate_output.path(output_type)); </ins> if !sess.opts.cg.save_temps && !keep_numbered { // The user just wants `foo.x`, not `foo.0.x`. remove(sess, &crate_output.with_extension(ext));

let link_obj = |output_path: &Path| { // Running `ld -r` on a single input is kind of pointless. if sess.opts.cg.codegen_units == 1 { <del> fs::copy(&crate_output.with_extension("0.o"), output_path).unwrap(); </del> <ins> copy_gracefully(&crate_output.with_extension("0.o"), output_path); </ins> // Leave the .0.o file around, to mimic the behavior of the normal // code path. return;
Change:
takes a object as reference, although it only clones it afterwards. It's also impossible to re-use the allocation for the file path, because it's only dropped at the end.
It is pretty hard to not involve allocations because Rust-native strings will have to be converted into null terminated one to pass into the native API at some point anyway.
That's true.. Maybe we can avoid the double-allocation?
The path is cloned only so that it can later be used in error messages, which is a somewhat debatable use case. We could resolve this in the future by taking an bound (if we had a trait like that). cc
In that case it would probably be better to just take a PathBuf. But does it really justify an extra allocation just to provide error messages?
That would be a lot less ergonomic -- I want to be able to feed in a string literal with no extra steps. Probably not, hence why I said it was a "somewhat debatable use case." :)
What about a variable-length stack allocation?
allocating on stack comes with its own downsides. Also, it doesn’t guarantee a trailing null byte either, AFAIK?
If you had a stack allocation, you could just append a null byte.
As tbu- said. And the downsides of are nothing compared to linking in 195kB of jemalloc (the absolute minimum jemalloc size on OS X x86_64 with LTO).

Discussion:
#[stable(feature = "rust1", since = "1.0.0")] pub struct File { inner: fs_imp::File, <del> path: Option<PathBuf>, </del> } /// Metadata information about a file.

OpenOptions::new().write(true).create(true).truncate(true).open(path) } <del> /// Returns the original path that was used to open this file. </del> <ins> /// Returns `None`. </ins> #[unstable(feature = "file_path", <del> reason = "this abstraction is imposed by this library instead  of the underlying OS and may be removed")] </del> <ins> reason = "this abstraction was imposed by this library and was removed")] #[deprecated(since = "1.0.0", reason = "abstraction was removed")] </ins> pub fn path(&self) -> Option<&Path> { <del> self.path.as_ref().map(|p| &**p) </del> <ins> None </ins> } /// Attempt to sync all OS-internal metadata to disk.

} impl FromInner<fs_imp::File> for File { fn from_inner(f: fs_imp::File) -> File { <del> File { inner: f, path: None } </del> <ins> File { inner: f } </ins> } }

pub fn open<P: AsRef<Path>>(&self, path: P) -> io::Result<File> { let path = path.as_ref(); let inner = try!(fs_imp::File::open(path, &self.0)); <del> Ok(File { path: Some(path.to_path_buf()), inner: inner }) </del> <ins> Ok(File { inner: inner }) </ins> } }
Change:
Currently, requires its argument to be strictly less than the length of the list, which means the following function panics when passed a one-element list. Instead, it should leave the original list unmodified and return an empty list: In contrast, does allow as a valid argument, so the above code works as desired if you replace DList with Vec.
Vec was actually like this until a few days ago when I happened to notice it and change the check. I must've mis-specified it in the RFC, or this went viral from the first mis-write.

Discussion:
/// Splits the list into two at the given index. Returns everything after the given index, /// including the index. /// <ins> /// # Panics /// /// Panics if `at > len`. /// </ins> /// This operation should compute in O(n) time. <ins> /// </ins> /// # Examples /// /// ```

#[stable(feature = "rust1", since = "1.0.0")] pub fn split_off(&mut self, at: usize) -> DList<T> { let len = self.len(); <del> assert!(at < len, "Cannot split off at a nonexistent index"); </del> <ins> assert!(at <= len, "Cannot split off at a nonexistent index"); </ins> if at == 0 { return mem::replace(self, DList::new()); <ins> } else if at == len { return DList::new(); </ins> } // Below, we iterate towards the `i-1`th node, either from the start or the end,

} } <ins> // no-op on the last index { let mut m = DList::new(); m.push_back(1); let p = m.split_off(1); assert_eq!(m.len(), 1); assert_eq!(p.len(), 0); assert_eq!(m.back(), Some(&1)); assert_eq!(m.front(), Some(&1)); } </ins> } #[test]
Change:
I tried to get a minimal example, now i just ended up with completely senseless code, that still gives the error. playpen says: if you remove the for loop, only the last two cat_expr notes are left. adding more code just ends up with more of the notes.
this is pretty much my fault. :) In all the cases that I have seen where it arises, it is due to a type error (or a type inference failure at at least) somewhere in the code. Of course the notes are incredibly annoying. I will try to fix.
And of course the concrete example given here is one where there is no type error. At least, not one exposed by compiling this code. (I have not yet managed to show being instantiated concretely without causing some other type error to arise.)
(but there may be a mix of bugs causing the original input here to pass. In particular, the code in the description is doing , but that associated type does not exist. One needs . See also: )
cc

Discussion:
expr.span); } Err(..) => { <del> rcx.fcx.tcx().sess.span_note(expr.span, "cat_expr_unadjusted Errd during dtor check"); </del> <ins> let tcx = rcx.fcx.tcx(); if tcx.sess.has_errors() { // cannot run dropck; okay b/c in error state anyway. } else { tcx.sess.span_bug(expr.span, "cat_expr_unadjusted Errd"); } </ins> } } }

check_safety_of_rvalue_destructor_if_necessary(rcx, head_cmt, expr.span); } Err(..) => { <del> rcx.fcx.tcx().sess.span_note(expr.span, "cat_expr Errd during dtor check"); </del> <ins> let tcx = rcx.fcx.tcx(); if tcx.sess.has_errors() { // cannot run dropck; okay b/c in error state anyway. } else { tcx.sess.span_bug(expr.span, "cat_expr Errd"); } </ins> } }