Question:
The std docs should list: The version they were built with The build date They could be at the top or bottom of every page, or on a stand-alone page like About or Help. This may not be important on rust- where I think they are rebuilt with every push but it seems like a good idea. It might be more useful on other sites where it isn't rebuilt for every push.
I don't think this is a problem with std itself, since the version is in the URL (or it's master, which was built in the past 24 hours).
Not sure where you std docs URL doesn't list a version. I don't think it will be a problem for Rust long-term. Once stable, the address will probably be something like with version varying between versions.
Partly a dupe of
Yes, this is basically a dup of /

**Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

let stability_index = time(time_passes, "stability index", (), |_| stability::Index::build(krate)); <ins> time(time_passes, "static item recursion checking", (), |_| middle::check_static_recursion::check_crate(&sess, krate, &def_map, &ast_map)); </ins> let ty_cx = ty::mk_ctxt(sess, type_arena, def_map,


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

pub mod borrowck; pub mod cfg; pub mod check_const; <ins> pub mod check_static_recursion; </ins> pub mod check_loop; pub mod check_match; pub mod check_rvalues;


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

// except according to those terms. <del> use driver::session::Session; </del> use middle::def::*; <del> use middle::resolve; </del> use middle::ty; use middle::typeck; use util::ppaux; use syntax::ast::*; <del> use syntax::{ast_util, ast_map}; </del> <ins> use syntax::ast_util; </ins> use syntax::visit::Visitor; use syntax::visit;


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

match it.node { ItemStatic(_, _, ref ex) => { v.inside_const(|v| v.visit_expr(&**ex)); <del> check_item_recursion(&v.tcx.sess, &v.tcx.map, &v.tcx.def_map, it); </del> } ItemEnum(ref enum_definition, _) => { for var in (*enum_definition).variants.iter() {


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

} visit::walk_expr(v, e); } <del> struct CheckItemRecursionVisitor<'a, 'ast: 'a> { root_it: &'a Item, sess: &'a Session, ast_map: &'a ast_map::Map<'ast>, def_map: &'a resolve::DefMap, idstack: Vec<NodeId> } // Make sure a const item doesn't recursively refer to itself // FIXME: Should use the dependency graph when it's available (#1356) pub fn check_item_recursion<'a>(sess: &'a Session, ast_map: &'a ast_map::Map, def_map: &'a resolve::DefMap, it: &'a Item) { let mut visitor = CheckItemRecursionVisitor { root_it: it, sess: sess, ast_map: ast_map, def_map: def_map, idstack: Vec::new() }; visitor.visit_item(it); } impl<'a, 'ast, 'v> Visitor<'v> for CheckItemRecursionVisitor<'a, 'ast> { fn visit_item(&mut self, it: &Item) { if self.idstack.iter().any(|x| x == &(it.id)) { self.sess.span_fatal(self.root_it.span, "recursive constant"); } self.idstack.push(it.id); visit::walk_item(self, it); self.idstack.pop(); } fn visit_expr(&mut self, e: &Expr) { match e.node { ExprPath(..) => { match self.def_map.borrow().find(&e.id) { Some(&DefStatic(def_id, _)) if ast_util::is_local(def_id) => { self.visit_item(&*self.ast_map.expect_item(def_id.node)); } _ => () } }, _ => () } visit::walk_expr(self, e); } } </del>


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

<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. // This compiler pass detects static items that refer to themselves // recursively. use driver::session::Session; use middle::resolve; use middle::def::DefStatic; use syntax::ast::{Crate, Expr, ExprPath, Item, ItemStatic, NodeId}; use syntax::{ast_util, ast_map}; use syntax::visit::Visitor; use syntax::visit; struct CheckCrateVisitor<'a, 'ast: 'a> { sess: &'a Session, def_map: &'a resolve::DefMap, ast_map: &'a ast_map::Map<'ast> } impl<'v, 'a, 'ast> Visitor<'v> for CheckCrateVisitor<'a, 'ast> { fn visit_item(&mut self, i: &Item) { check_item(self, i); } } pub fn check_crate<'ast>(sess: &Session, krate: &Crate, def_map: &resolve::DefMap, ast_map: &ast_map::Map<'ast>) { let mut visitor = CheckCrateVisitor { sess: sess, def_map: def_map, ast_map: ast_map }; visit::walk_crate(&mut visitor, krate); sess.abort_if_errors(); } fn check_item(v: &mut CheckCrateVisitor, it: &Item) { match it.node { ItemStatic(_, _, ref ex) => { check_item_recursion(v.sess, v.ast_map, v.def_map, it); visit::walk_expr(v, &**ex) }, _ => visit::walk_item(v, it) } } struct CheckItemRecursionVisitor<'a, 'ast: 'a> { root_it: &'a Item, sess: &'a Session, ast_map: &'a ast_map::Map<'ast>, def_map: &'a resolve::DefMap, idstack: Vec<NodeId> } // Make sure a const item doesn't recursively refer to itself // FIXME: Should use the dependency graph when it's available (#1356) pub fn check_item_recursion<'a>(sess: &'a Session, ast_map: &'a ast_map::Map, def_map: &'a resolve::DefMap, it: &'a Item) { let mut visitor = CheckItemRecursionVisitor { root_it: it, sess: sess, ast_map: ast_map, def_map: def_map, idstack: Vec::new() }; visitor.visit_item(it); } impl<'a, 'ast, 'v> Visitor<'v> for CheckItemRecursionVisitor<'a, 'ast> { fn visit_item(&mut self, it: &Item) { if self.idstack.iter().any(|x| x == &(it.id)) { self.sess.span_err(self.root_it.span, "recursive constant"); return; } self.idstack.push(it.id); visit::walk_item(self, it); self.idstack.pop(); } fn visit_expr(&mut self, e: &Expr) { match e.node { ExprPath(..) => { match self.def_map.borrow().find(&e.id) { Some(&DefStatic(def_id, _)) if ast_util::is_local(def_id) => { self.visit_item(&*self.ast_map.expect_item(def_id.node)); } _ => () } }, _ => () } visit::walk_expr(self, e); } } </ins>


Question:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

<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. static FOO: uint = FOO; //~ ERROR recursive constant fn main() { let _x: [u8, ..FOO]; // caused stack overflow prior to fix let _y: uint = 1 + { static BAR: uint = BAR; //~ ERROR recursive constant let _z: [u8, ..BAR]; // caused stack overflow prior to fix 1 }; } </ins>


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

euv::AutoRef(..) | euv::ClosureInvocation(..) | euv::ForLoop(..) | <del> euv::RefBinding(..) => { </del> <ins> euv::RefBinding(..) | euv::MatchDiscriminant(..) => { </ins> format!("previous borrow of `{}` occurs here", self.bccx.loan_path_to_string(&*old_loan.loan_path)) }


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

euv::AddrOf | euv::RefBinding | euv::AutoRef | <del> euv::ForLoop => { </del> <ins> euv::ForLoop | euv::MatchDiscriminant => { </ins> format!("cannot borrow {} as mutable", descr) } euv::ClosureInvocation => {


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

BorrowViolation(euv::OverloadedOperator) | BorrowViolation(euv::AddrOf) | BorrowViolation(euv::AutoRef) | <del> BorrowViolation(euv::RefBinding) => { </del> <ins> BorrowViolation(euv::RefBinding) | BorrowViolation(euv::MatchDiscriminant) => { </ins> "cannot borrow data mutably" }


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

OverloadedOperator, ClosureInvocation, ForLoop, <ins> MatchDiscriminant </ins> } #[deriving(PartialEq,Show)]


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

} ast::ExprMatch(ref discr, ref arms) => { <del> // treatment of the discriminant is handled while // walking the arms: self.walk_expr(&**discr); </del> let discr_cmt = return_if_err!(self.mc.cat_expr(&**discr)); <ins> self.borrow_expr(&**discr, ty::ReEmpty, ty::ImmBorrow, MatchDiscriminant); // treatment of the discriminant is handled while walking the arms. </ins> for arm in arms.iter() { self.walk_arm(discr_cmt.clone(), arm); }


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

ref s => { tcx.sess.span_bug( span, <del> format!("ty_region() invoked on in appropriate ty: {:?}", </del> <ins> format!("ty_region() invoked on an inappropriate ty: {:?}", </ins> s).as_slice()); } }


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

<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 foo(_s: i16) { } fn bar(_s: u32) { } fn main() { foo(1*(1 as int)); //~^ ERROR: mismatched types: expected `i16`, found `int` (expected `i16`, found `int`) bar(1*(1 as uint)); //~^ ERROR: mismatched types: expected `u32`, found `uint` (expected `u32`, found `uint`) } </ins>


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

<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. struct X(int); enum Enum { Variant1, Variant2 } impl Drop for X { fn drop(&mut self) {} } impl Drop for Enum { fn drop(&mut self) {} } fn main() { let foo = X(1i); drop(foo); match foo { //~ ERROR use of moved value X(1i) => (), _ => unreachable!() } let e = Variant2; drop(e); match e { //~ ERROR use of moved value Variant1 => unreachable!(), Variant2 => () } } </ins>


Question:
Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.

<del> // 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 foo(_s: i16) { } fn bar(_s: u32) { } fn main() { foo(1*(1 as int)); //~^ ERROR: mismatched types: expected `i16`, found `int` (expected `i16`, found `int`) bar(1*(1 as uint)); //~^ ERROR: mismatched types: expected `u32`, found `uint` (expected `u32`, found `uint`) } </del>


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

{ let parent = self.get_parent(id); let parent = match self.find_entry(id) { <del> Some(EntryForeignItem(..)) | Some(EntryVariant(..)) => { // Anonymous extern items, enum variants and struct ctors // go in the parent scope. </del> <ins> Some(EntryForeignItem(..)) => { // Anonymous extern items go in the parent scope. </ins> self.get_parent(parent) } // But tuple struct ctors don't have names, so use the path of its


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

prim_ty_to_ty(tcx, base_segments, prim_ty) } _ => { <ins> let node = def.def_id().node; </ins> span_err!(tcx.sess, span, E0248, <del> "found value name used as a type: {:?}", *def); </del> <ins> "found value `{}` used as a type", tcx.map.path_to_string(node)); </ins> return this.tcx().types.err; } }


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

Bar } <del> fn foo(x: Foo::Bar) {} //~ERROR found value name used as a type </del> <ins> fn foo(x: Foo::Bar) {} //~ERROR found value `Foo::Bar` used as a type </ins> fn main() {}


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

<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. use foo::MyEnum::Result; use foo::NoResult; // Through a re-export mod foo { pub use self::MyEnum::NoResult; enum MyEnum { Result, NoResult } fn new() -> NoResult<MyEnum, String> { //~^ ERROR: found value `foo::MyEnum::NoResult` used as a type unimplemented!() } } mod bar { use foo::MyEnum::Result; use foo; fn new() -> Result<foo::MyEnum, String> { //~^ ERROR: found value `foo::MyEnum::Result` used as a type unimplemented!() } } fn new() -> Result<foo::MyEnum, String> { //~^ ERROR: found value `foo::MyEnum::Result` used as a type unimplemented!() } fn newer() -> NoResult<foo::MyEnum, String> { //~^ ERROR: found value `foo::MyEnum::NoResult` used as a type unimplemented!() } fn main() { let _ = new(); } </ins>


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

#[rustc_move_fragments] pub fn test_match_partial(p: Lonely<D, D>) { //~^ ERROR                 parent_of_fragments: `$(local p)` <del> //~| ERROR                  assigned_leaf_path: `($(local p) as Zero)` </del> <ins> //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Zero)` </ins> match p { Zero(..) => {} _ => {}


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

#[rustc_move_fragments] pub fn test_match_full(p: Lonely<D, D>) { //~^ ERROR                 parent_of_fragments: `$(local p)` <del> //~| ERROR                  assigned_leaf_path: `($(local p) as Zero)` //~| ERROR                  assigned_leaf_path: `($(local p) as One)` //~| ERROR                  assigned_leaf_path: `($(local p) as Two)` </del> <ins> //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Zero)` //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::One)` //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Two)` </ins> match p { Zero(..) => {} One(..) => {}


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

#[rustc_move_fragments] pub fn test_match_bind_one(p: Lonely<D, D>) { //~^ ERROR                 parent_of_fragments: `$(local p)` <del> //~| ERROR                  assigned_leaf_path: `($(local p) as Zero)` //~| ERROR                 parent_of_fragments: `($(local p) as One)` //~| ERROR                     moved_leaf_path: `($(local p) as One).#0` //~| ERROR                  assigned_leaf_path: `($(local p) as Two)` </del> <ins> //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Zero)` //~| ERROR                 parent_of_fragments: `($(local p) as Lonely::One)` //~| ERROR                     moved_leaf_path: `($(local p) as Lonely::One).#0` //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Two)` </ins> //~| ERROR                  assigned_leaf_path: `$(local data)` match p { Zero(..) => {}


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

#[rustc_move_fragments] pub fn test_match_bind_many(p: Lonely<D, D>) { //~^ ERROR                 parent_of_fragments: `$(local p)` <del> //~| ERROR                  assigned_leaf_path: `($(local p) as Zero)` //~| ERROR                 parent_of_fragments: `($(local p) as One)` //~| ERROR                     moved_leaf_path: `($(local p) as One).#0` </del> <ins> //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Zero)` //~| ERROR                 parent_of_fragments: `($(local p) as Lonely::One)` //~| ERROR                     moved_leaf_path: `($(local p) as Lonely::One).#0` </ins> //~| ERROR                  assigned_leaf_path: `$(local data)` <del> //~| ERROR                 parent_of_fragments: `($(local p) as Two)` //~| ERROR                     moved_leaf_path: `($(local p) as Two).#0` //~| ERROR                     moved_leaf_path: `($(local p) as Two).#1` </del> <ins> //~| ERROR                 parent_of_fragments: `($(local p) as Lonely::Two)` //~| ERROR                     moved_leaf_path: `($(local p) as Lonely::Two).#0` //~| ERROR                     moved_leaf_path: `($(local p) as Lonely::Two).#1` </ins> //~| ERROR                  assigned_leaf_path: `$(local left)` //~| ERROR                  assigned_leaf_path: `$(local right)` match p {


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

<del> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2014-2015 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //


Question:
Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)

#[rustc_move_fragments] pub fn test_match_bind_and_underscore(p: Lonely<D, D>) { //~^ ERROR                 parent_of_fragments: `$(local p)` <del> //~| ERROR                  assigned_leaf_path: `($(local p) as Zero)` //~| ERROR                  assigned_leaf_path: `($(local p) as One)` //~| ERROR                 parent_of_fragments: `($(local p) as Two)` //~| ERROR                     moved_leaf_path: `($(local p) as Two).#0` //~| ERROR                    unmoved_fragment: `($(local p) as Two).#1` </del> <ins> //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::Zero)` //~| ERROR                  assigned_leaf_path: `($(local p) as Lonely::One)` //~| ERROR                 parent_of_fragments: `($(local p) as Lonely::Two)` //~| ERROR                     moved_leaf_path: `($(local p) as Lonely::Two).#0` //~| ERROR                    unmoved_fragment: `($(local p) as Lonely::Two).#1` </ins> //~| ERROR                  assigned_leaf_path: `$(local left)` match p {


Question:
Hi, I've been giving rust a try and hit my first compiler bug today. I was playing around with traits and ran into an error with the following code: In particular it seems it's the last line in that breaks things, if I comment that out it compiles (and runs) without issue. Here's output from rustc: I am using on OS X 10.9.4
Looke like this no longer ICE-s: Now produces: Which seems like the right error message. Please reopen if you are still having trouble. Please reopen if you are still

**Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.


Question:
Some of core methods using macros. Like and of and . I found two primary things about this: () (, ) Seems like some of fail (panic) methods will be preserved (like for a ). But using of such methods is highly error-prone. To prevent mass usage of them I suggest to mark such methods as . For example:
is used for operations that are memory unsafe. marking (supposed) code smells as would only pollute when or when not to use it. notice memory unsafe is a very clear definition, unsafe does not mean this code might be broken, per se. (as i understand this)
is for drawing a boundary between memory unsafe and memory safe code It's not used to discourage the usage of safe APIs as that would break down the boundary and make it harder to identify memory safety issues. Usage of and is common in correct code, because there are invariants that are not encoded into the type system. Changing the meaning of would be a fundamental change to the design of the language / libraries so it would need to go through the RFC process (but it wouldn't be accepted).
(now at )


Question:
Let's say that you have a JSON document similar to this: And the value of can be either a number or a string. There is currently no way to write a generic implementation of that can handle this. Attempting to read the value of will remove it and throw it away, even if the read triggers an error. You can't try to read a number and then read a string if it fails. The element is returned in the , so it should be possible to write an implementation of specifically for Json, but if you do so you can't put the object within another object that has .
Can it not map to the enum?
The enum doesn't implement . It's probably for this reason.
Duplicate of Should I close this?


Question:
Code: Compile, run, result is Sorry, cannot find smaller example to reproduce the problem. Similar code, internal compiler error:
Smaller:
Looks like a libstd bug: could you file a separate issue for the internal compiler error?

impl<'a> Writer for &'a mut Writer+'a { #[inline] <del> fn write(&mut self, buf: &[u8]) -> IoResult<()> { self.write(buf) } </del> <ins> fn write(&mut self, buf: &[u8]) -> IoResult<()> { (**self).write(buf) } </ins> #[inline] <del> fn flush(&mut self) -> IoResult<()> { self.flush() } </del> <ins> fn flush(&mut self) -> IoResult<()> { (**self).flush() } </ins> } /// A `RefWriter` is a struct implementing `Writer` which contains a reference


Question:
Noticed in . This is either a really odd way to ask for the version, or a bit of advice that's no longer relevant. What should we say instead? is a bit too_ verbose — I killed it after it wrote 8.1 GB of logs compiling .
I think the intent was indeed to get the version output. I think the phrasing is only odd in that it does not make that intent clear. (It is possible I am wrong about the intent here.) But there is an additional problem: Sometime between 0.10 and 0.11, we revised the / output to ensure it would be only one line when you do not supply an argument to . This means we lose potentially relevant information, namely the host system type (e.g. or ). We could fix both of these problems by revising the instructions to say something like:
Closing since was merged.

It generally helps our diagnosis to include your specific OS (for example: Mac OS X 10.8.3, Windows 7, Ubuntu 12.04) and your hardware architecture (for example: i686, x86_64). <del> It's also helpful to copy/paste the output of re-running the erroneous rustc command with the `-v` flag. Finally, if you can run the offending command under gdb, pasting a stack trace can be useful; to do so, you will need to set a breakpoint on `rust_fail`. </del> <ins> It's also helpful to provide the exact version and host by copying the output of re-running the erroneous rustc command with the `--version=verbose` flag, which will produce something like this: ```{ignore} rustc 0.12.0 (ba4081a5a 2014-10-07 13:44:41 -0700) binary: rustc commit-hash: ba4081a5a8573875fed17545846f6f6902c8ba8d commit-date: 2014-10-07 13:44:41 -0700 host: i686-apple-darwin release: 0.12.0 ``` Finally, if you can run the offending command under gdb, pasting a stack trace can be useful; to do so, you will need to set a breakpoint on `rust_fail`. </ins> # I submitted a bug, but nobody has commented on it!


Question:
When trying to do development on the stage1 compiler, I've been hitting a link error. I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler. But we can and should still try to increase the coverage of bors to handle at least building from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
In case anyone is curious, the problem also occurs on Linux. I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , then things proceed just fine. This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)
(I edited the PR description but forgot that github closes issues based on the original commit message.) I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the build itself, and also adding rules that will force bors to gate on continuing to build.

# Some less critical tests that are not prone to breakage. # Not run as part of the normal test suite, but tested by bors on checkin. <del> check-secondary: check-lexer check-pretty </del> <ins> check-secondary: check-build-compiletest check-lexer check-pretty </ins> # check + check-secondary. <del> check-all: check check-secondary </del> <ins> # # Issue #17883: build check-secondary first so hidden dependencies in # e.g. building compiletest are exercised (resolve those by adding # deps to rules that need them; not by putting `check` first here). check-all: check-secondary check </ins> # Pretty-printing tests. check-pretty: check-stage2-T-$(CFG_BUILD)-H-$(CFG_BUILD)-pretty-exec <ins> define DEF_CHECK_BUILD_COMPILETEST_FOR_STAGE check-stage$(1)-build-compiletest: 	$$(HBIN$(1)_H_$(CFG_BUILD))/compiletest$$(X_$(CFG_BUILD)) endef $(foreach stage,$(STAGES),  $(eval $(call DEF_CHECK_BUILD_COMPILETEST_FOR_STAGE,$(stage)))) check-build-compiletest:  check-stage1-build-compiletest  check-stage2-build-compiletest </ins> .PHONY: cleantmptestlogs cleantestlibs cleantmptestlogs:


Question:
When trying to do development on the stage1 compiler, I've been hitting a link error. I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler. But we can and should still try to increase the coverage of bors to handle at least building from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
In case anyone is curious, the problem also occurs on Linux. I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , then things proceed just fine. This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)
(I edited the PR description but forgot that github closes issues based on the original commit message.) I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the build itself, and also adding rules that will force bors to gate on continuing to build.

PRETTY_DEPS_pretty-rfail = $(RFAIL_TESTS) PRETTY_DEPS_pretty-bench = $(BENCH_TESTS) PRETTY_DEPS_pretty-pretty = $(PRETTY_TESTS) <ins> # The stage- and host-specific dependencies are for e.g. macro_crate_test which pulls in # external crates. PRETTY_DEPS$(1)_H_$(3)_pretty-rpass = PRETTY_DEPS$(1)_H_$(3)_pretty-rpass-full = $$(HLIB$(1)_H_$(3))/stamp.syntax $$(HLIB$(1)_H_$(3))/stamp.rustc PRETTY_DEPS$(1)_H_$(3)_pretty-rfail = PRETTY_DEPS$(1)_H_$(3)_pretty-bench = PRETTY_DEPS$(1)_H_$(3)_pretty-pretty = </ins> PRETTY_DIRNAME_pretty-rpass = run-pass PRETTY_DIRNAME_pretty-rpass-full = run-pass-fulldeps PRETTY_DIRNAME_pretty-rfail = run-fail


Question:
When trying to do development on the stage1 compiler, I've been hitting a link error. I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler. But we can and should still try to increase the coverage of bors to handle at least building from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
In case anyone is curious, the problem also occurs on Linux. I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , then things proceed just fine. This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)
(I edited the PR description but forgot that github closes issues based on the original commit message.) I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the build itself, and also adding rules that will force bors to gate on continuing to build.

$$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)):  $$(TEST_SREQ$(1)_T_$(2)_H_$(3))  <del> $$(PRETTY_DEPS_$(4)) </del> <ins> $$(PRETTY_DEPS_$(4))  $$(PRETTY_DEPS$(1)_H_$(3)_$(4)) </ins> @$$(call E, run pretty-rpass [$(2)]: $$<) $$(Q)$$(call CFG_RUN_CTEST_$(2),$(1),$$<,$(3))  $$(PRETTY_ARGS$(1)-T-$(2)-H-$(3)-$(4))


Question:
Technically speaking the negative duration is not the valid ISO 8601, but we need to print it anyway. This code: Produces: Should be , in fact Should be , in fact
Cc

impl fmt::Show for Duration { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> let days = self.num_days(); let secs = self.secs - days * SECS_PER_DAY; </del> <ins> // technically speaking, negative duration is not valid ISO 8601, // but we need to print it anyway. let (abs, sign) = if self.secs < 0 { (-self, "-") } else { (*self, "") }; let days = abs.secs / SECS_PER_DAY; let secs = abs.secs - days * SECS_PER_DAY; </ins> let hasdate = days != 0; <del> let hastime = (secs != 0 || self.nanos != 0) || !hasdate; </del> <ins> let hastime = (secs != 0 || abs.nanos != 0) || !hasdate; try!(write!(f, "{}P", sign)); </ins> <del> try!(write!(f, "P")); </del> if hasdate { <del> // technically speaking the negative part is not the valid ISO 8601, // but we need to print it anyway. </del> try!(write!(f, "{}D", days)); } if hastime { <del> if self.nanos == 0 { </del> <ins> if abs.nanos == 0 { </ins> try!(write!(f, "T{}S", secs)); <del> } else if self.nanos % NANOS_PER_MILLI == 0 { try!(write!(f, "T{}.{:03}S", secs, self.nanos / NANOS_PER_MILLI)); } else if self.nanos % NANOS_PER_MICRO == 0 { try!(write!(f, "T{}.{:06}S", secs, self.nanos / NANOS_PER_MICRO)); </del> <ins> } else if abs.nanos % NANOS_PER_MILLI == 0 { try!(write!(f, "T{}.{:03}S", secs, abs.nanos / NANOS_PER_MILLI)); } else if abs.nanos % NANOS_PER_MICRO == 0 { try!(write!(f, "T{}.{:06}S", secs, abs.nanos / NANOS_PER_MICRO)); </ins> } else { <del> try!(write!(f, "T{}.{:09}S", secs, self.nanos)); </del> <ins> try!(write!(f, "T{}.{:09}S", secs, abs.nanos)); </ins> } } Ok(())


Question:
Technically speaking the negative duration is not the valid ISO 8601, but we need to print it anyway. This code: Produces: Should be , in fact Should be , in fact
Cc

let d: Duration = Zero::zero(); assert_eq!(d.to_string(), "PT0S".to_string()); assert_eq!(Duration::days(42).to_string(), "P42D".to_string()); <del> assert_eq!(Duration::days(-42).to_string(), "P-42D".to_string()); </del> <ins> assert_eq!(Duration::days(-42).to_string(), "-P42D".to_string()); </ins> assert_eq!(Duration::seconds(42).to_string(), "PT42S".to_string()); assert_eq!(Duration::milliseconds(42).to_string(), "PT0.042S".to_string()); assert_eq!(Duration::microseconds(42).to_string(), "PT0.000042S".to_string()); assert_eq!(Duration::nanoseconds(42).to_string(), "PT0.000000042S".to_string()); assert_eq!((Duration::days(7) + Duration::milliseconds(6543)).to_string(), "P7DT6.543S".to_string()); <ins> assert_eq!(Duration::seconds(-86401).to_string(), "-P1DT1S".to_string()); assert_eq!(Duration::nanoseconds(-1).to_string(), "-PT0.000000001S".to_string()); </ins> // the format specifier should have no effect on `Duration` assert_eq!(format!("{:30}", Duration::days(1) + Duration::milliseconds(2345)),


Question:
Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?

return found def make_win_dist(dist_root, target_triple): <del> # Ask gcc where it keeps its' stuff </del> <ins> # Ask gcc where it keeps its stuff </ins> gcc_out = subprocess.check_output(["gcc.exe", "-print-search-dirs"]) bin_path = os.environ["PATH"].split(os.pathsep) lib_path = []


Question:
Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?

else: rustc_dlls.append("libgcc_s_seh-1.dll") <del> target_libs = ["crtbegin.o", "crtend.o", "crt2.o", "dllcrt2.o", "libadvapi32.a", "libcrypt32.a", "libgcc.a", "libgcc_eh.a", "libgcc_s.a", "libimagehlp.a", "libiphlpapi.a", "libkernel32.a", "libm.a", "libmingw32.a", "libmingwex.a", "libmsvcrt.a", "libpsapi.a", "libshell32.a", "libstdc++.a", "libuser32.a", "libws2_32.a", "libiconv.a", "libmoldname.a"] </del> <ins> target_libs = [ # MinGW libs "crtbegin.o", "crtend.o", "crt2.o", "dllcrt2.o", "libgcc.a", "libgcc_eh.a", "libgcc_s.a", "libm.a", "libmingw32.a", "libmingwex.a", "libstdc++.a", "libiconv.a", "libmoldname.a", # Windows import libs "libadvapi32.a", "libbcrypt.a", "libcomctl32.a", "libcomdlg32.a", "libcrypt32.a", "libctl3d32.a", "libgdi32.a", "libimagehlp.a", "libiphlpapi.a", "libkernel32.a", "libmsvcrt.a", "libodbc32.a", "libole32.a", "liboleaut32.a", "libopengl32.a", "libpsapi.a", "librpcrt4.a", "libsetupapi.a", "libshell32.a", "libuser32.a", "libuuid.a", "libwinhttp.a", "libwinmm.a", "libwinspool.a", "libws2_32.a", "libwsock32.a", ] </ins> # Find mingw artifacts we want to bundle target_tools = find_files(target_tools, bin_path)


Question:
Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?

shutil.copy(src, dist_bin_dir) # Copy platform tools to platform-specific bin directory <del> target_bin_dir = os.path.join(dist_root, "bin", "rustlib", target_triple, "gcc", "bin") </del> <ins> target_bin_dir = os.path.join(dist_root, "bin", "rustlib", target_triple, "bin") </ins> if not os.path.exists(target_bin_dir): os.makedirs(target_bin_dir) for src in target_tools: shutil.copy(src, target_bin_dir) # Copy platform libs to platform-spcific lib directory <del> target_lib_dir = os.path.join(dist_root, "bin", "rustlib", target_triple, "gcc", "lib") </del> <ins> target_lib_dir = os.path.join(dist_root, "bin", "rustlib", target_triple, "lib") </ins> if not os.path.exists(target_lib_dir): os.makedirs(target_lib_dir) for src in target_libs:


Question:
Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?

cmd.arg(obj_filename.with_extension("metadata.o")); } <del> // Rust does its' own LTO cmd.arg("-fno-lto"); </del> if t.options.is_like_osx { // The dead_strip option to the linker specifies that functions and data // unreachable by the entry point will be removed. This is quite useful


Question:
Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?

trans: &CrateTranslation, outputs: &OutputFilenames) { let old_path = os::getenv("PATH").unwrap_or_else(||String::new()); <del> let mut new_path = os::split_paths(old_path.as_slice()); new_path.extend(sess.host_filesearch().get_tools_search_paths().into_iter()); </del> <ins> let mut new_path = sess.host_filesearch().get_tools_search_paths(); new_path.extend(os::split_paths(old_path.as_slice()).into_iter()); </ins> os::setenv("PATH", os::join_paths(new_path.as_slice()).unwrap()); time(sess.time_passes(), "linking", (), |_|


Question:
Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?

p.push(find_libdir(self.sysroot)); p.push(rustlibdir()); p.push(self.triple); <del> let mut p1 = p.clone(); p1.push("bin"); let mut p2 = p.clone(); p2.push("gcc"); p2.push("bin"); vec![p1, p2] </del> <ins> p.push("bin"); vec![p] </ins> } }


Question:
The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.

unsafe { let ccx = cx.fcx.ccx; let ty = val_ty(fn_); <del> let retty = if ty.kind() == llvm::Integer { </del> <ins> let retty = if ty.kind() == llvm::Function { </ins> ty.return_type() } else { ccx.int_type()


Question:
The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.

<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. // error-pattern:stop // #18576 // Make sure that an calling extern function pointer in an unreachable // context doesn't cause an LLVM assertion #[allow(unreachable_code)] fn main() { panic!("stop"); let pointer = other; pointer(); } extern fn other() {} </ins>


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

use common::{CodegenCx, val_ty}; use declare; use monomorphize::Instance; <ins> use syntax_pos::Span; use syntax_pos::symbol::LocalInternedString; </ins> use type_::Type; use type_of::LayoutLlvmExt; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::layout::{Align, LayoutOf}; <del> use rustc::hir::{self, CodegenFnAttrFlags}; </del> <ins> use rustc::hir::{self, CodegenFnAttrs, CodegenFnAttrFlags}; </ins> use std::ffi::{CStr, CString};


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

let ty = instance.ty(cx.tcx); let sym = cx.tcx.symbol_name(instance).as_str(); <ins> debug!("get_static: sym={} instance={:?}", sym, instance); </ins> let g = if let Some(id) = cx.tcx.hir.as_local_node_id(def_id) { let llty = cx.layout_of(ty).llvm_type(cx);


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

hir_map::NodeForeignItem(&hir::ForeignItem { ref attrs, span, node: hir::ForeignItemKind::Static(..), .. }) => { <del> let g = if let Some(linkage) = cx.tcx.codegen_fn_attrs(def_id).linkage { // If this is a static with a linkage specified, then we need to handle // it a little specially. The typesystem prevents things like &T and // extern "C" fn() from being non-null, so we can't just declare a // static and call it a day. Some linkages (like weak) will make it such // that the static actually has a null value. let llty2 = match ty.sty { ty::TyRawPtr(ref mt) => cx.layout_of(mt.ty).llvm_type(cx), _ => { cx.sess().span_fatal(span, "must have type `*const T` or `*mut T`"); } }; unsafe { // Declare a symbol `foo` with the desired linkage. let g1 = declare::declare_global(cx, &sym, llty2); llvm::LLVMRustSetLinkage(g1, base::linkage_to_llvm(linkage)); // Declare an internal global `extern_with_linkage_foo` which // is initialized with the address of `foo`.  If `foo` is // discarded during linking (for example, if `foo` has weak // linkage and there are no definitions), then // `extern_with_linkage_foo` will instead be initialized to // zero. let mut real_name = "_rust_extern_with_linkage_".to_string(); real_name.push_str(&sym); let g2 = declare::define_global(cx, &real_name, llty).unwrap_or_else(||{ cx.sess().span_fatal(span, &format!("symbol `{}` is already defined", &sym)) }); llvm::LLVMRustSetLinkage(g2, llvm::Linkage::InternalLinkage); llvm::LLVMSetInitializer(g2, g1); g2 } } else { // Generate an external declaration. declare::declare_global(cx, &sym, llty) }; (g, attrs) </del> <ins> let fn_attrs = cx.tcx.codegen_fn_attrs(def_id); (check_and_apply_linkage(cx, &fn_attrs, ty, sym, Some(span)), attrs) </ins> } item => bug!("get_static: expected static, found {:?}", item) }; <ins> debug!("get_static: sym={} attrs={:?}", sym, attrs); </ins> for attr in attrs { if attr.check_name("thread_local") { llvm::set_thread_local_mode(g, cx.tls_model);


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

g } else { // FIXME(nagisa): perhaps the map of externs could be offloaded to llvm somehow? <del> // FIXME(nagisa): investigate whether it can be changed into define_global let g = declare::declare_global(cx, &sym, cx.layout_of(ty).llvm_type(cx)); </del> <ins> debug!("get_static: sym={} item_attr={:?}", sym, cx.tcx.item_attrs(def_id)); let attrs = cx.tcx.codegen_fn_attrs(def_id); let g = check_and_apply_linkage(cx, &attrs, ty, sym, None); </ins> // Thread-local statics in some other crate need to *always* be linked // against in a thread-local fashion, so we need to be sure to apply the // thread-local attribute locally if it was present remotely. If we // don't do this then linker errors can be generated where the linker // complains that one object files has a thread local version of the // symbol and another one doesn't. <del> for attr in cx.tcx.get_attrs(def_id).iter() { if attr.check_name("thread_local") { llvm::set_thread_local_mode(g, cx.tls_model); } </del> <ins> if attrs.flags.contains(CodegenFnAttrFlags::THREAD_LOCAL) { llvm::set_thread_local_mode(g, cx.tls_model); </ins> } if cx.use_dll_storage_attrs && !cx.tcx.is_foreign_item(def_id) { // This item is external but not foreign, i.e. it originates from an external Rust // crate. Since we don't know whether this crate will be linked dynamically or


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

g } <ins> fn check_and_apply_linkage<'tcx>( cx: &CodegenCx<'_, 'tcx>, attrs: &CodegenFnAttrs, ty: Ty<'tcx>, sym: LocalInternedString, span: Option<Span> ) -> ValueRef { let llty = cx.layout_of(ty).llvm_type(cx); if let Some(linkage) = attrs.linkage { debug!("get_static: sym={} linkage={:?}", sym, linkage); // If this is a static with a linkage specified, then we need to handle // it a little specially. The typesystem prevents things like &T and // extern "C" fn() from being non-null, so we can't just declare a // static and call it a day. Some linkages (like weak) will make it such // that the static actually has a null value. let llty2 = match ty.sty { ty::TyRawPtr(ref mt) => cx.layout_of(mt.ty).llvm_type(cx), _ => { if span.is_some() { cx.sess().span_fatal(span.unwrap(), "must have type `*const T` or `*mut T`") } else { bug!("must have type `*const T` or `*mut T`") } } }; unsafe { // Declare a symbol `foo` with the desired linkage. let g1 = declare::declare_global(cx, &sym, llty2); llvm::LLVMRustSetLinkage(g1, base::linkage_to_llvm(linkage)); // Declare an internal global `extern_with_linkage_foo` which // is initialized with the address of `foo`.  If `foo` is // discarded during linking (for example, if `foo` has weak // linkage and there are no definitions), then // `extern_with_linkage_foo` will instead be initialized to // zero. let mut real_name = "_rust_extern_with_linkage_".to_string(); real_name.push_str(&sym); let g2 = declare::define_global(cx, &real_name, llty).unwrap_or_else(||{ if span.is_some() { cx.sess().span_fatal( span.unwrap(), &format!("symbol `{}` is already defined", &sym) ) } else { bug!("symbol `{}` is already defined", &sym) } }); llvm::LLVMRustSetLinkage(g2, llvm::Linkage::InternalLinkage); llvm::LLVMSetInitializer(g2, g1); g2 } } else { // Generate an external declaration. // FIXME(nagisa): investigate whether it can be changed into define_global declare::declare_global(cx, &sym, llty) } } </ins> pub fn codegen_static<'a, 'tcx>( cx: &CodegenCx<'a, 'tcx>, def_id: DefId,


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

<ins> // Copyright 2018 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. #![crate_type = "rlib"] #![feature(linkage)] pub fn foo<T>() -> *const() { extern { #[linkage = "extern_weak"] static FOO: *const(); } unsafe { FOO } } </ins>


Question:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

<ins> // Copyright 2018 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. // Test for issue #18804, #[linkage] does not propagate thorugh generic // functions. Failure results in a linker error. // ignore-asmjs no weak symbol support // ignore-emscripten no weak symbol support // aux-build:lib.rs extern crate lib; fn main() { lib::foo::<i32>(); } </ins>


Question:
This was the smallest I could make it. Commenting out the lines for either or or making and the same type allows compilation to finish successfully. Error: What I don't understand is: why in the world is it even complaining about implementations when no one is using ? Is this some sort of weird interaction with trait object types? (rustc at commit , Linux)
I've been seeing this too, any time I have a trait with two associated types that are different. Still happens as of the current nightly. Strangely, if you make them the same (i.e. "type T0 = f32; type T1 = f32;" in the impl), the error goes away.
This seems to be fixed. The example compiles on

<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 Tup { type T0; type T1; } impl Tup for isize { type T0 = f32; type T1 = (); } fn main() {} </ins>