jiebi/CodeConvo huggingface dataset:
Change:
Consider the following code: The behaviour of this code depends on whether the guard applies to only the pattern it succeeds, or to the entire match arm. Running it on nightly behaves as though the guard applies to the entire arm (i.e. the first arm is not matched), but this is not stipulated anywhere in the docs as far as I can tell. If this interpretation of the code is indeed the expected one, then this should be documented.
It is expected as far as I know.

Discussion:
This prints `Got an int!`. <ins> If you’re using `if` with multiple patterns, the `if` applies to both sides: ```rust let x = 4; let y = false; match x { 4 | 5 if y => println!("yes"), _ => println!("no"), } ``` This prints `no`, because the `if` applies to the whole of `4 | 5`, and not to just the `5`, In other words, the the precedence of `if` behaves like this: ```text (4 | 5) if y => ... ``` not this: ```text 4 | (5 if y) => ... ``` </ins> # ref and ref mut If you want to get a [reference][ref], use the `ref` keyword:
Change:
Attempting to compile the following with my  crate yields an ICE: Output from
Reduced:
I'm able to reproduce this exact same error on stable and nightly today using this 8 line example:

Discussion:
use middle::def_id::DefId; use middle::subst::{self, SelfSpace, TypeSpace}; use middle::traits; <del> use middle::ty::{self, ToPolyTraitRef, Ty}; </del> <ins> use middle::ty::{self, HasTypeFlags, ToPolyTraitRef, Ty}; </ins> use std::rc::Rc; use syntax::ast;

data.0.trait_ref.substs.types.get_slice(TypeSpace) .iter() .cloned() <del> .any(is_self) </del> <ins> .any(|t| t.has_self_ty()) </ins> } ty::Predicate::Projection(..) | ty::Predicate::WellFormed(..) |

.any(|predicate| { match predicate { ty::Predicate::Trait(ref trait_pred) if trait_pred.def_id() == sized_def_id => { <del> is_self(trait_pred.0.self_ty()) </del> <ins> trait_pred.0.self_ty().is_self() </ins> } ty::Predicate::Projection(..) | ty::Predicate::Trait(..) |

error } <del> fn is_self<'tcx>(ty: Ty<'tcx>) -> bool { match ty.sty { ty::TyParam(ref data) => data.space == subst::SelfSpace, _ => false, } } </del>

<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. trait MapLookup<Q> { type MapValue; } impl<K> MapLookup<K> for K { type MapValue = K; } trait Map: MapLookup<<Self as Map>::Key> { type Key; } impl<K> Map for K { type Key = K; } fn main() { let _ = &() as &Map<Key=u32,MapValue=u32>; //~^ ERROR the trait `Map` cannot be made into an object //~| NOTE the trait cannot use `Self` as a type parameter } </ins>
Change:
I don't think this has been reported yet. I think better error handling in would make this go away.

Discussion:
use serialize::json; use std::env; <del> use std::ffi::OsString; </del> <ins> use std::ffi::{OsString, OsStr}; </ins> use std::fs; use std::io::{self, Write}; use std::path::{Path, PathBuf};

OutputFilenames { out_directory: out_file.parent().unwrap_or(cur_dir).to_path_buf(), <del> out_filestem: out_file.file_stem().unwrap() </del> <ins> out_filestem: out_file.file_stem().unwrap_or(OsStr::new("")) </ins> .to_str().unwrap().to_string(), single_output_file: ofile, extra: sess.opts.cg.extra_filename.clone(),

<ins> -include ../tools.mk all: $(RUSTC) -o "" blank.rs 2>&1 |  grep 'No such file or directory' </ins>

<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. fn main() {} </ins>
Change:
LLVM error: The problem seems to be that some part of LLVM does not like the we generate for zero-sized types. cc

Discussion:
if !type_is_zero_size(ccx, result_ty) { alloc_ty(bcx, result_ty, "constructor_result") } else { <del> C_undef(type_of::type_of(ccx, result_ty)) </del> <ins> C_undef(type_of::type_of(ccx, result_ty).ptr_to()) </ins> } } };

<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. trait Tr { type T; } impl Tr for u8 { type T=(); } struct S<I: Tr>(I::T); fn foo<I: Tr>(i: I::T) { S::<I>(i); } fn main() { foo::<u8>(()); } </ins>
Change:
Testcase: Yields: Auto-deref should be picking DerefMut here, not Deref.
I just ran into this problem too, here's a shorter example: And playpen link:
Further reduced:
:
And again
Just got this today, with what is almost identical to Mark-Simulacrum's reduced version.
I've also run into this issue, with this example: and this error:
This error seems resolved. Examples above all work on stable.

Discussion:
<ins> // check-pass use std::sync::Mutex; use std::cell::RefCell; use std::rc::Rc; use std::ops::*; //eefriedman example struct S<'a, T:FnMut() + 'static + ?Sized>(&'a mut T); impl<'a, T:?Sized + FnMut() + 'static> DerefMut for S<'a, T> { fn deref_mut(&mut self) -> &mut Self::Target { &mut self.0 } } impl<'a, T:?Sized + FnMut() + 'static> Deref for S<'a, T> { type Target = dyn FnMut() + 'a; fn deref(&self) -> &Self::Target { &self.0 } } //Ossipal example struct FunctionIcon { get_icon: Mutex<Box<dyn FnMut() -> u32>>, } impl FunctionIcon { fn get_icon(&self) -> impl '_ + std::ops::DerefMut<Target=Box<dyn FnMut() -> u32>> { self.get_icon.lock().unwrap() } fn load_icon(&self)  { let mut get_icon = self.get_icon(); let _rgba_icon = (*get_icon)(); } } //shepmaster example struct Foo; impl Deref for Foo { type Target = dyn FnMut() + 'static; fn deref(&self) -> &Self::Target { unimplemented!() } } impl DerefMut for Foo { fn deref_mut(&mut self) -> &mut Self::Target { unimplemented!() } } fn main() { //eefriedman example let mut f = ||{}; let mut s = S(&mut f); s(); //Diggsey/Mark-Simulacrum example let a: Rc<RefCell<dyn FnMut()>> = Rc::new(RefCell::new(||{})); a.borrow_mut()(); //shepmaster example let mut t = Foo; t(); } </ins>
Change:
I'm looking at , and trying to find out the thread-safety of . Along the way, I noticed that , despite I'm allergic to Windows, so I've no idea what might cause this dangerous return value.
While it may be nice to have a comment to this effect, I don't think that this is a problem. The only time we actually look at the pointer is during iteration, and that only happens if the count/range returns an item. In the case that NULL is returned the count will be 0, so the pointer is never looked at. Additionally, ignores NULL pointer arguments, so I don't think that there's actually a problem here. All that being said, though, a comment would be nice.

Discussion:
impl Drop for Args { fn drop(&mut self) { <ins> // self.cur can be null if CommandLineToArgvW previously failed, // but LocalFree ignores NULL pointers </ins> unsafe { c::LocalFree(self.cur as *mut c_void); } } }

let lpCmdLine = c::GetCommandLineW(); let szArgList = c::CommandLineToArgvW(lpCmdLine, &mut nArgs); <ins> // szArcList can be NULL if CommandLinToArgvW failed, // but in that case nArgs is 0 so we won't actually // try to read a null pointer </ins> Args { cur: szArgList, range: 0..(nArgs as isize) } } }
Change:
You can create an inherent impl where the impl substs are not constrained by the impl signature. If the parameters are constrained by the method signature, you can even get code that usefully runs (otherwise you get "can't resolve" errors): Note that you need to use UFCS notation to avoid (which is an issue with method lookup). RFC447 is silent with regards to this issue, but this allows you to create an impl that is not resolvable by its trait-ref.
cc
Heh, I was just telling in IRC the other day that this case was broken. I agree, the current logic is too simplistic (it's also something I've been writing up in this RFC I keep talking about...). Basically, it currently considers all input/type parameters which appear as constrianed, but it ought to stop at projections. I made this gist, which is a similar example:
To be clear, I don't think that fixing this issue requires an RFC (it's just a bug, I think). I just meant that I was writing up various text that referenced the notion of "constrained type parameters" and tried to give a definition, which is how I realized this problem.

Discussion:
Region(ty::EarlyBoundRegion), } <ins> /// Returns the list of parameters that are constrained by the type `ty` /// - i.e. the value of each parameter in the list is uniquely determined /// by `ty` (see RFC 447). </ins> pub fn parameters_for_type<'tcx>(ty: Ty<'tcx>) -> Vec<Parameter> { <del> ty.walk() .flat_map(|ty| parameters_for_type_shallow(ty)) .collect() </del> <ins> let mut result = vec![]; ty::maybe_walk_ty(ty, |t| { if let ty::TyProjection(..) = t.sty { false // projections are not injective. } else { result.append(&mut parameters_for_type_shallow(t)); // non-projection type constructors are injective. true } }); result </ins> } pub fn parameters_for_trait_ref<'tcx>(trait_ref: &ty::TraitRef<'tcx>) -> Vec<Parameter> {

<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. // Check that projections don't count as constraining type parameters. struct S<T>(T); trait Tr { type Assoc; fn test(); } impl<T: Tr> S<T::Assoc> { //~^ ERROR the type parameter `T` is not constrained fn foo(self, _: T) { T::test(); } } trait Trait1<T> { type Bar; } trait Trait2<'x> { type Foo; } impl<'a,T: Trait2<'a>> Trait1<<T as Trait2<'a>>::Foo> for T { //~^ ERROR the lifetime parameter `'a` is not constrained type Bar = &'a (); } fn main() {} </ins>
Change:
Right before the "move closures" section, the book doesn't really make it clear that this code would not compile: It shows part of the compile error, but it just looks like a non-error message from the compiler. Consider appending "the error message" to "This gives us".

Discussion:
``` If your closure requires it, however, Rust will take ownership and move <del> the environment instead: </del> <ins> the environment instead. This doesn’t work: </ins> ```rust,ignore let nums = vec![1, 2, 3];

println!("{:?}", nums); ``` <del> This gives us: </del> <ins> We get this error: </ins> ```text note: `nums` moved into closure environment here because it has type
Change:
Also .
Like any good bug, turning on debugging changes behaviour (VERBOSE=1). It creates a directory called ' From make output:
Found the problem, making PR.

Discussion:
# Create a directory # $(1) is the directory <ins> # # XXX: These defines are called to generate make steps. # Adding blank lines means two steps from different defines will not end up on # the same line. </ins> define PREPARE_DIR <del> @$(Q)$(call E, prepare: $(1)) </del> <ins> @$(call E, prepare: $(1)) </ins> $(Q)$(PREPARE_DIR_CMD) $(1) endef # Copy an executable # $(1) is the filename/libname-glob # <del> # Gee, what's up with that $(nop)? See comment below. </del> <ins> # See above for an explanation on the surrounding blank lines </ins> define PREPARE_BIN <del> $(nop) </del> @$(call E, prepare: $(PREPARE_DEST_BIN_DIR)/$(1)) $(Q)$(PREPARE_BIN_CMD) $(PREPARE_SOURCE_BIN_DIR)/$(1) $(PREPARE_DEST_BIN_DIR)/$(1) endef # Copy a dylib or rlib # $(1) is the filename/libname-glob # <del> # XXX: Don't remove the $(nop) command below! # Yeah, that's right, it's voodoo. Something in the way this macro is being expanded # causes it to parse incorrectly. Throwing in that empty command seems to fix the # problem. I'm sorry, just don't remove the $(nop), alright? </del> <ins> # See above for an explanation on the surrounding blank lines </ins> define PREPARE_LIB <del> $(nop) </del> @$(call E, prepare: $(PREPARE_WORKING_DEST_LIB_DIR)/$(1)) $(Q)LIB_NAME="$(notdir $(lastword $(wildcard $(PREPARE_WORKING_SOURCE_LIB_DIR)/$(1))))";  MATCHES="$(filter-out %$(notdir $(lastword $(wildcard $(PREPARE_WORKING_SOURCE_LIB_DIR)/$(1)))), 

echo $$MATCHES ;  fi $(Q)$(PREPARE_LIB_CMD) `ls -drt1 $(PREPARE_WORKING_SOURCE_LIB_DIR)/$(1)` $(PREPARE_WORKING_DEST_LIB_DIR)/ endef # Copy a man page # $(1) - source dir <ins> # # See above for an explanation on the surrounding blank lines </ins> define PREPARE_MAN @$(call E, prepare: $(PREPARE_DEST_MAN_DIR)/$(1)) $(Q)$(PREPARE_MAN_CMD) $(PREPARE_SOURCE_MAN_DIR)/$(1) $(PREPARE_DEST_MAN_DIR)/$(1) endef PREPARE_TOOLS = $(filter-out compiletest rustbook error-index-generator, $(TOOLS))
Change:
I am reading here: I also checked the nightly docs, which are the same. The example says: However, I did not see any other mention of . It seems like it should probably be the name of a formal argument to .
1i32 = one i32. Fonts...
Ouch, I did not see that at all. How about making it "79i32" or something like that?
Alternatively, we could ditch the serifed font.

Discussion:
fn inverse<T>() -> T // this is using ConvertTo as if it were "ConvertFrom<i32>" where i32: ConvertTo<T> { <del> 1i32.convert() </del> <ins> 42.convert() </ins> } ```
Change:
In the in the section it is stated that (emphasis mine) But the example shows a type parameter on , which requires parenthesis-enclosed type parameters rather than angle-brackets. mentioned on IRC that this might be some special case to open the possibility to easier change the traits at a later time (if I understood correctly), but I found it confusing to see a specialization using parenthesis without ever having heard they existed.
Isn't the text referring to Those angle brackets? "following the function name"
Yeah, I suspect the real confusion here is that the syntax with parens has not yet been introduced (nor is it explained anywhere, apparently), so it's the wrong example at this point in the document, and it's not clear to a first-time reader what is being referred to. It seems like there should be a sufficient example here that doesn't use closures, maybe one simple one with and , and one using traits over collections or iterators or something, to demonstrate that parameterized types can appear in the bounds, to make it easier to understand. That said, the reference is explicitly not intended to be pedagogical, and implicitly not yet expected to be complete.

Discussion:
signature. Each type parameter must be explicitly declared, in an angle-bracket-enclosed, comma-separated list following the function name. <del> ```{.ignore} fn iter<T, F>(seq: &[T], f: F) where T: Copy, F: Fn(T) { for elt in seq { f(*elt); } } fn map<T, U, F>(seq: &[T], f: F) -> Vec<U> where T: Copy, U: Copy, F: Fn(T) -> U { let mut acc = vec![]; for elt in seq { acc.push(f(*elt)); } acc } </del> <ins> ```rust,ignore // foo is generic over A and B fn foo<A, B>(x: A, y: B) { </ins> ``` Inside the function signature and body, the name of the type parameter can be used as a type name. [Trait](#traits) bounds can be specified for type parameters to allow methods with that trait to be called on values of that type. This is <del> specified using the `where` syntax, as in the above example. </del> <ins> specified using the `where` syntax: ```rust,ignore fn foo<T>(x: T) where T: Debug { ``` </ins> When a generic function is referenced, its type is instantiated based on the context of the reference. For example, calling the `iter` function defined
Change:
Please see this StackOverflow <a href=""question</a.
Interesting: rustc -C llvm-args='--list' gives the option list for LLC you might expect llvm-args would be passed to clang (which has the options described in the stack overflow page), and indeed to which these arguments were formerly passed. edit: but it also doesn't seem to be the case recently, as both stable and nightly seem to pass args to llc, not clang.
I think this may actually be a real thing. See . It throws the error: But llc definitely takes this argument. I've traced the argument parsing to . And now that I try it, doesn't seem to work for me either. I'm running . Btw, I ran into this trying to work around .
Added code to print the argv passed to . It prints the args from . So I guess the problem is that llc args != whatever arguments that function expects.
Yes, that appears to be the case. The arguments recognized by and the arguments recognized by the API are different. The Rust compiler uses the LLVM API, so it doesn't recognize certain LLVM options even though they may be valid for . Consider the following: Compile with and execute with . It will print the following: Compare that with the output for (an exercise left to the reader). I need the and for my target, as . I don't know what the solution is here. Is it something for LLVM to solve, or something for rustc to solve?
I'm leaving this open because it's not clear to me how a user should pass arguments directly to llc if they want to; perhaps that's not possible or even something we want. Could you comment on whether we think it's a good idea to allow passing arguments into llc directly? Do we run llc at all? If we don't then it seems that this is not a bug.
Nominating to decide whether we want to expose llc or not (and if we can -- I don't know that we run it directly today). If not, we should close.
I'm moving this to T-dev-tools; it seems like they've put some energy into how to think about the stability of well.
cc this seems like something that would be a tooling/platform team issue if that team existed.
Briefly discussed at the dev-tools meeting: verdict was that this did not seem urgent to address.
Related
Leaving this here in case it's helpful to anyone who comes across this issue: I was able to get what appears to be the full list of the arguments LLVM will accept by way of with: Caution: sharp edges abound.
Exposing these flags would be a matter of using , if we really want to.

Discussion:
#include "llvm/Analysis/AliasAnalysis.h" #include "llvm/Analysis/TargetLibraryInfo.h" #include "llvm/Analysis/TargetTransformInfo.h" <ins> #include "llvm/CodeGen/CommandFlags.h" </ins> #include "llvm/CodeGen/TargetSubtargetInfo.h" #include "llvm/IR/AutoUpgrade.h" #include "llvm/IR/AssemblyAnnotationWriter.h"

using namespace llvm; <ins> static codegen::RegisterCodeGenFlags CGF; </ins> typedef struct LLVMOpaquePass *LLVMPassRef; typedef struct LLVMOpaqueTargetMachine *LLVMTargetMachineRef;

return nullptr; } <del> TargetOptions Options; </del> <ins> TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags(Trip); </ins> Options.FloatABIType = FloatABI::Default; if (UseSoftFloat) {
Change:
In the unsafe section: It occurs in 4-5 depending on how you count: unsafe fn unsafe trait unsafe block unsafe impl In my TURPL draft I currently state the following: Their are several places can appear in Rust today, which can largely be grouped into two categories: There are unchecked contracts here. To declare you understand this, I require you to write elsewhere: On functions, is declaring the function to be unsafe to call. Users of the function must check the documentation to determine what this means, and then have to write somewhere to identify that they're aware of the danger. On trait declarations, is declaring that implementing the trait is an unsafe operation, as it has contracts that other unsafe code is free to trust blindly. I am declaring that I have, to the best of my knowledge, adhered to the unchecked contracts: On trait implementations, is declaring that the contract of the trait has been upheld. On blocks, is declaring any unsafety from an unsafe operation to be handled, and therefore the parent function is safe. There is also , which is a special case that exists for historical reasons and is in the process of being phased out. See the section on destructors for details.
Note that Send and Sync are the only two stable unsafe traits, but there are more in the unstable pipeline.
Is the only unsafe attribute?
To my knowledge. We used to have or whatever but dropck has subsumed it.

Discussion:
than normal code does. Let’s go over the syntax, and then we’ll talk semantics. `unsafe` is used in <del> two contexts. The first one is to mark a function as unsafe: </del> <ins> four contexts. The first one is to mark a function as unsafe: </ins> ```rust unsafe fn danger_will_robinson() {

} ``` <ins> The third is for unsafe traits: ```rust unsafe trait Scary { } ``` And the fourth is for `impl`ementing one of those traits: ```rust # unsafe trait Scary { } unsafe impl Scary for i32 {} ``` </ins> It’s important to be able to explicitly delineate code that may have bugs that cause big problems. If a Rust program segfaults, you can be sure it’s somewhere in the sections marked `unsafe`.
Change:
from the unsafe section: Doing any of these things is Undefined Behaviour that should be impossible for a safe code to do under any circumstance. Code is unsafe if there are circumstances under which it may do one of these things (bad inputs, bad state).

Discussion:
# What does ‘safe’ mean? <del> Safe, in the context of Rust, means “doesn’t do anything unsafe.” Easy! </del> <ins> Safe, in the context of Rust, means ‘doesn’t do anything unsafe’. It’s also important to know that there are certain behaviors that are probably not desirable in your code, but are expressly _not_ unsafe: </ins> <del> Okay, let’s try again: what is not safe to do? Here’s a list: </del> <ins> * Deadlocks * Leaks of memory or other resources * Exiting without calling destructors * Integer overflow Rust cannot prevent all kinds of software problems. Buggy code can and will be written in Rust. These things aren’t great, but they don’t qualify as `unsafe` specifically. In addition, the following are all undefined behaviors in Rust, and must be avoided, even when writing `unsafe` code: </ins> * Data races * Dereferencing a null/dangling raw pointer

[undef]: http://llvm.org/docs/LangRef.html#undefined-values [aliasing]: http://llvm.org/docs/LangRef.html#pointer-aliasing-rules <del> Whew! That’s a bunch of stuff. It’s also important to notice all kinds of behaviors that are certainly bad, but are expressly _not_ unsafe: * Deadlocks * Leaks of memory or other resources * Exiting without calling destructors * Integer overflow Rust cannot prevent all kinds of software problems. Buggy code can and will be written in Rust. These things aren’t great, but they don’t qualify as `unsafe` specifically. </del> # Unsafe Superpowers In both unsafe functions and unsafe blocks, Rust will let you do three things
Change:
When you search, the document title remains the same as the last page you were on. This is quite confusing if you look through your tab's browsing history. For example, you might see something like: (newest) std::cmp::Eq - Rust std::borrow::Borrow - Rust std::borrow::Borrow - Rust (oldest) However, the second entry takes you to the page "Results for eq". The title of that page should also be "Results for eq".
Agreed, I often end up going back to a search page because it didn't look like one in the list.

Discussion:
return; } <ins> // Update document title to maintain a meaningful browser history $(document).prop("title", "Results for " + query.query + " - Rust"); </ins> // Because searching is incremental by character, only the most // recent search query is added to the browser history. if (browserSupportsHistoryApi()) {