Question:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = |r: f64| if r != 0.0(r != 0.0) { 1.0 } else { 0.0 }; //~^ ERROR expected function, found `{float}` } </ins>


Question:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #45662 #![feature(repr_align)] #![feature(attr_literals)] #[repr(align(16))] pub struct A { y: i64, } pub extern "C" fn foo(x: A) {} fn main() {} </ins>


Question:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(conservative_impl_trait)] use std::iter::once; struct Foo { x: i32, } impl Foo { fn inside(&self) -> impl Iterator<Item = &i32> { once(&self.x) } } fn main() { println!("hi"); } </ins>


Question:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(unsize, coerce_unsized)] #[repr(packed)] struct UnalignedPtr<'a, T: ?Sized> where T: 'a, { data: &'a T, } fn main() { impl<'a, T, U> std::ops::CoerceUnsized<UnalignedPtr<'a, U>> for UnalignedPtr<'a, T> where T: std::marker::Unsize<U> + ?Sized, U: ?Sized, { } let arr = [1, 2, 3]; let arr_unaligned: UnalignedPtr<[i32; 3]> = UnalignedPtr { data: &arr }; let arr_unaligned: UnalignedPtr<[i32]> = arr_unaligned; } </ins>


Question:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #42164 #![feature(decl_macro)] #![allow(dead_code)] pub macro m($inner_str:expr) { #[doc = $inner_str] struct S; } macro_rules! define_f { ($name:expr) => { #[export_name = $name] fn f() {} } } fn main() { define_f!(concat!("exported_", "f")); m!(stringify!(foo)); } </ins>


Question:
Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> use rustc_serialize::{Encodable, Decodable, Encoder, Decoder}; </del> use rustc_data_structures::stable_hasher; use std::mem; use std::slice; <del> #[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Clone, Copy)] </del> <ins> #[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Clone, Copy, RustcEncodable, RustcDecodable)] </ins> pub struct Fingerprint(u64, u64); impl Fingerprint {


Question:
Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:

} } <del> impl Encodable for Fingerprint { #[inline] fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { s.emit_u64(self.0.to_le())?; s.emit_u64(self.1.to_le()) } } impl Decodable for Fingerprint { #[inline] fn decode<D: Decoder>(d: &mut D) -> Result<Fingerprint, D::Error> { let _0 = u64::from_le(d.read_u64()?); let _1 = u64::from_le(d.read_u64()?); Ok(Fingerprint(_0, _1)) } } </del> impl ::std::fmt::Display for Fingerprint { fn fmt(&self, formatter: &mut ::std::fmt::Formatter) -> Result<(), ::std::fmt::Error> { write!(formatter, "{:x}-{:x}", self.0, self.1)


Question:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!

let ast::Path { ref segments, span } = *path; let path: Vec<_> = segments.iter().map(|seg| respan(seg.span, seg.identifier)).collect(); let invocation = self.invocations[&scope]; <del> self.current_module = invocation.module.get(); </del> <ins> let module = invocation.module.get(); self.current_module = if module.is_trait() { module.parent.unwrap() } else { module }; </ins> if path.len() > 1 { if !self.use_extern_macros && self.gated_errors.insert(span) {


Question:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:attr-on-trait.rs #![feature(proc_macro)] extern crate attr_on_trait; trait Foo { #[attr_on_trait::foo] fn foo() {} } impl Foo for i32 { fn foo(&self) {} } fn main() { 3i32.foo(); } </ins>


Question:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![feature(proc_macro)] #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn foo(attr: TokenStream, item: TokenStream) -> TokenStream { drop(attr); assert_eq!(item.to_string(), "fn foo() { }"); "fn foo(&self);".parse().unwrap() } </ins>


Question: Tracking issue for the lib feature for the column info API in the panic location hook mechanism, in PR .

/// # Examples /// /// ```should_panic <del> /// #![feature(panic_col)] </del> /// use std::panic; /// /// panic::set_hook(Box::new(|panic_info| {


Question: Tracking issue for the lib feature for the column info API in the panic location hook mechanism, in PR .

/// /// panic!("Normal panic"); /// ``` <del> #[unstable(feature = "panic_col", reason = "recently added", issue = "42939")] </del> <ins> #[stable(feature = "panic_col", since = "1.25")] </ins> pub fn column(&self) -> u32 { self.col }


Question:
Test case: With rustc 1.20.0-nightly ( 2017-07-06), output when compiling with : correctly stops the dead code / unused type alias warning from being shown, but the trait bounds not enforced warning is shown anyway. Per and , this might be on purpose. I think this is the wrong decision. The point of is to allow Cargo to inhibit warnings in external dependencies. When building Servo it is not useful to spam the console with many warnings, future-proofing or not, about code that Servo has not direct control over. CC
Nominating for discussion. Not sure if compiler team or lang team is best, though, so tagging both...
From the lang team's point of view: definitely a bug.
Couple of bugs here: First off, we should not be ignoring the bounds in types. And sometimes they are needed. I'd like to fix this by not ignoring them, but I worry about the backcompat issues. Unknown risk there. Second, if we must warn, we should be emitting a regular lint that can be silenced. Plausibly, we should just remove the warning (eliminating the immediate problem), and prioritize trying to do a proper fix here.
Somewhat related to not ignoring bounds (but in the other direction): .
After some discussion in compiler team, decided to move this to a "future compatibility" lint, one that we will hopefully make more precise over time. Right now the check is not very good. At least this means you won't have to see it. We need some mentoring instructions though!
Some tips here:
triage: P-medium
I've hit this recently. It seems like it is possible to write code that requires exactly this bound. So it is quite bad that we cannot suppress this warning. Example code:
Agreed, this is poor. There just hasn't been a lot of energy to try and improve the situation.
Fixed in , probably by We should add a regression test for this particular case before we close this issue however, since I don't think the test in the PR detects a regression for the problem described in this issue. The problem in this issue is output on stderr, not that compilation fails ( exit code is 0 both with and without the fix in the PR). label E-needs-test

<ins> // Regression test for https://github.com/rust-lang/rust/issues/43134 // check-pass // compile-flags: --cap-lints allow type Foo<T: Clone> = Option<T>; fn main() {} </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<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. // only-x86_64 #![allow(dead_code, non_upper_case_globals)] #![feature(asm)] #[repr(C)] pub struct D32x4(f32,f32,f32,f32); impl D32x4 { fn add(&self, vec: Self) -> Self { unsafe { let ret: Self; asm!(" movaps $1, %xmm1 movaps $2, %xmm2 addps %xmm1, %xmm2 movaps $xmm1, $0 " : "=r"(ret) : "1"(self), "2"(vec) : "xmm1", "xmm2" ); ret } } } fn main() { } </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<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. const C: *const u8 = &0; fn foo(x: *const u8) { match x { C => {} _ => {} } } const D: *const [u8; 4] = b"abcd"; fn main() { match D { D => {} _ => {} } } </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<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. pub trait Foo<'a> { type Bar; fn foo(&'a self) -> Self::Bar; } impl<'a, 'b, T: 'a> Foo<'a> for &'b T { type Bar = &'a T; fn foo(&'a self) -> &'a T { self } } pub fn uncallable<T, F>(x: T, f: F) where T: for<'a> Foo<'a>, F: for<'a> Fn(<T as Foo<'a>>::Bar) { f(x.foo()); } pub fn catalyst(x: &i32) { broken(x, |_| {}) } pub fn broken<F: Fn(&i32)>(x: &i32, f: F) { uncallable(x, |y| f(y)); } fn main() { } </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<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. fn main() { let thing = (); let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant //~^ ERROR `typeof` is a reserved keyword but unimplemented [E0516] } fn f(){ let q = 1; <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant //~^ ERROR `typeof` is a reserved keyword but unimplemented [E0516] } </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<ins> error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-42060.rs:13:23 | LL |     let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant |                       ^^^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-42060.rs:19:13 | LL |     <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant |             ^ non-constant value error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-42060.rs:13:16 | LL |     let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant |                ^^^^^^^^^^^^^ reserved keyword error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-42060.rs:19:6 | LL |     <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant |      ^^^^^^^^^ reserved keyword error: aborting due to 4 previous errors Some errors occurred: E0435, E0516. For more information about an error, try `rustc --explain E0435`. </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<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. fn main() { | } //~^ ERROR expected `|`, found `}` | //~^ ERROR expected item, found `|` </ins>


Question:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

<ins> error: expected `|`, found `}` --> $DIR/issue-43196.rs:13:1 | LL |     | |      - expected `|` here LL | } | ^ unexpected token error: expected item, found `|` --> $DIR/issue-43196.rs:15:1 | LL | | | ^ expected item error: aborting due to 2 previous errors </ins>


Question:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

use tvec; use value::Value; <del> use super::MirContext; </del> <ins> use super::{MirContext, LocalRef}; </ins> use super::constant::const_scalar_checked_binop; use super::operand::{OperandRef, OperandValue}; use super::lvalue::LvalueRef;


Question:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

} mir::Rvalue::Len(ref lvalue) => { <del> let tr_lvalue = self.trans_lvalue(&bcx, lvalue); </del> <ins> let size = self.evaluate_array_len(&bcx, lvalue); </ins> let operand = OperandRef { <del> val: OperandValue::Immediate(tr_lvalue.len(bcx.ccx)), </del> <ins> val: OperandValue::Immediate(size), </ins> ty: bcx.tcx().types.usize, }; (bcx, operand)


Question:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

} } <ins> fn evaluate_array_len(&mut self, bcx: &Builder<'a, 'tcx>, lvalue: &mir::Lvalue<'tcx>) -> ValueRef { // ZST are passed as operands and require special handling // because trans_lvalue() panics if Local is operand. if let mir::Lvalue::Local(index) = *lvalue { if let LocalRef::Operand(Some(op)) = self.locals[index] { if common::type_is_zero_size(bcx.ccx, op.ty) { if let ty::TyArray(_, n) = op.ty.sty { return common::C_uint(bcx.ccx, n); } } } } // use common size calculation for non zero-sized types let tr_value = self.trans_lvalue(&bcx, lvalue); return tr_value.len(bcx.ccx); } </ins> pub fn trans_scalar_binop(&mut self, bcx: &Builder<'a, 'tcx>, op: mir::BinOp,


Question:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { &&[()][0]; println!("{:?}", &[(),()][1]); } </ins>


Question:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

<ins> pub trait Trait<'a> { type Assoc; } pub struct Type; impl<'a> Trait<'a> for Type { type Assoc = (); } pub fn break_me<T, F>(f: F) where T: for<'b> Trait<'b>, F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { break_me::<Type, fn(_)>; //~^ ERROR: type mismatch in function arguments //~| ERROR: type mismatch resolving } fn main() {} </ins>


Question:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

<ins> error[E0631]: type mismatch in function arguments --> $DIR/issue-43623.rs:14:5 | LL |     break_me::<Type, fn(_)>; |     ^^^^^^^^^^^^^^^^^^^^^^^ |     | |     expected signature of `for<'b> fn(<Type as Trait<'b>>::Assoc) -> _` |     found signature of `fn(_) -> _` | note: required by `break_me` --> $DIR/issue-43623.rs:11:1 | LL | / pub fn break_me<T, F>(f: F) LL | | where T: for<'b> Trait<'b>, LL | |       F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { LL | |     break_me::<Type, fn(_)>; LL | | LL | | LL | | } | |_^ error[E0271]: type mismatch resolving `for<'b> <fn(_) as std::ops::FnOnce<(<Type as Trait<'b>>::Assoc,)>>::Output == ()` --> $DIR/issue-43623.rs:14:5 | LL |     break_me::<Type, fn(_)>; |     ^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter 'b, found concrete lifetime | note: required by `break_me` --> $DIR/issue-43623.rs:11:1 | LL | / pub fn break_me<T, F>(f: F) LL | | where T: for<'b> Trait<'b>, LL | |       F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { LL | |     break_me::<Type, fn(_)>; LL | | LL | | LL | | } | |_^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>


Question:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

<ins> use std::ops::Index; struct Test; struct Container(Test); impl Test { fn test(&mut self) {} } impl<'a> Index<&'a bool> for Container { type Output = Test; fn index(&self, _index: &'a bool) -> &Test { &self.0 } } fn main() { let container = Container(Test); let mut val = true; container[&mut val].test(); //~ ERROR: cannot borrow data } </ins>


Question:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

<ins> error[E0596]: cannot borrow data in an index of `Container` as mutable --> $DIR/issue-44405.rs:21:5 | LL |     container[&mut val].test(); |     ^^^^^^^^^^^^^^^^^^^ cannot borrow as mutable | = help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Container` error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

// Building with a static libstdc++ is only supported on linux right now, // not for MSVC or macOS if build.config.llvm_static_stdcpp && <ins> !target.contains("freebsd") && </ins> !target.contains("windows") && !target.contains("apple") { cargo.env("LLVM_STATIC_STDCPP",


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

libssl-dev  pkg-config <del> COPY dist-i686-freebsd/build-toolchain.sh /tmp/ RUN /tmp/build-toolchain.sh i686 </del> <ins> COPY scripts/freebsd-toolchain.sh /tmp/ RUN /tmp/freebsd-toolchain.sh i686 </ins> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV  AR_i686_unknown_freebsd=i686-unknown-freebsd10-ar  <del> CC_i686_unknown_freebsd=i686-unknown-freebsd10-gcc  CXX_i686_unknown_freebsd=i686-unknown-freebsd10-g++ </del> <ins> CC_i686_unknown_freebsd=i686-unknown-freebsd10-clang  CXX_i686_unknown_freebsd=i686-unknown-freebsd10-clang++ </ins> ENV HOSTS=i686-unknown-freebsd


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  <del> g++  </del> <ins> clang  </ins> make  file  curl


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

libssl-dev  pkg-config <del> COPY dist-x86_64-freebsd/build-toolchain.sh /tmp/ RUN /tmp/build-toolchain.sh x86_64 </del> <ins> COPY scripts/freebsd-toolchain.sh /tmp/ RUN /tmp/freebsd-toolchain.sh x86_64 </ins> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV  AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-ar  <del> CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-gcc  CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-g++ </del> <ins> CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-clang  CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-clang++ </ins> ENV HOSTS=x86_64-unknown-freebsd


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

<del> #!/usr/bin/env bash # Copyright 2016 The Rust Project Developers. See the COPYRIGHT # file at the top-level directory of this distribution and at # http://rust-lang.org/COPYRIGHT. # # Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or # http://www.apache.org/licenses/LICENSE-2.0> or the MIT license # <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your # option. This file may not be copied, modified, or distributed # except according to those terms. set -ex ARCH=$1 BINUTILS=2.25.1 GCC=6.4.0 hide_output() { set +x on_err=" echo ERROR: An error was encountered with the build. cat /tmp/build.log exit 1 " trap "$on_err" ERR bash -c "while true; do sleep 30; echo $(date) - building ...; done" & PING_LOOP_PID=$! $@ &> /tmp/build.log trap - ERR kill $PING_LOOP_PID set -x } mkdir binutils cd binutils # First up, build binutils curl https://ftp.gnu.org/gnu/binutils/binutils-$BINUTILS.tar.bz2 | tar xjf - mkdir binutils-build cd binutils-build hide_output ../binutils-$BINUTILS/configure  --target=$ARCH-unknown-freebsd10 hide_output make -j10 hide_output make install cd ../.. rm -rf binutils # Next, download the FreeBSD libc and relevant header files mkdir freebsd case "$ARCH" in x86_64) URL=ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/base.txz ;; i686) URL=ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/10.2-RELEASE/base.txz ;; esac curl $URL | tar xJf - -C freebsd ./usr/include ./usr/lib ./lib dst=/usr/local/$ARCH-unknown-freebsd10 cp -r freebsd/usr/include $dst/ cp freebsd/usr/lib/crt1.o $dst/lib cp freebsd/usr/lib/Scrt1.o $dst/lib cp freebsd/usr/lib/crti.o $dst/lib cp freebsd/usr/lib/crtn.o $dst/lib cp freebsd/usr/lib/libc.a $dst/lib cp freebsd/usr/lib/libutil.a $dst/lib cp freebsd/usr/lib/libutil_p.a $dst/lib cp freebsd/usr/lib/libm.a $dst/lib cp freebsd/usr/lib/librt.so.1 $dst/lib cp freebsd/usr/lib/libexecinfo.so.1 $dst/lib cp freebsd/lib/libc.so.7 $dst/lib cp freebsd/lib/libm.so.5 $dst/lib cp freebsd/lib/libutil.so.9 $dst/lib cp freebsd/lib/libthr.so.3 $dst/lib/libpthread.so ln -s libc.so.7 $dst/lib/libc.so ln -s libm.so.5 $dst/lib/libm.so ln -s librt.so.1 $dst/lib/librt.so ln -s libutil.so.9 $dst/lib/libutil.so ln -s libexecinfo.so.1 $dst/lib/libexecinfo.so rm -rf freebsd # Finally, download and build gcc to target FreeBSD mkdir gcc cd gcc curl https://ftp.gnu.org/gnu/gcc/gcc-$GCC/gcc-$GCC.tar.gz | tar xzf - cd gcc-$GCC ./contrib/download_prerequisites mkdir ../gcc-build cd ../gcc-build hide_output ../gcc-$GCC/configure                 --enable-languages=c,c++                        --target=$ARCH-unknown-freebsd10                --disable-multilib                              --disable-nls                                   --disable-libgomp                               --disable-libquadmath                           --disable-libssp                                --disable-libvtv                                --disable-libcilkrts                            --disable-libada                                --disable-libsanitizer                          --disable-libquadmath-support                   --disable-lto hide_output make -j10 hide_output make install cd ../.. rm -rf gcc </del>


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

<ins> #!/bin/bash # Copyright 2016-2017 The Rust Project Developers. See the COPYRIGHT # file at the top-level directory of this distribution and at # http://rust-lang.org/COPYRIGHT. # # Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or # http://www.apache.org/licenses/LICENSE-2.0> or the MIT license # <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your # option. This file may not be copied, modified, or distributed # except according to those terms. set -eux arch=$1 binutils_version=2.25.1 freebsd_version=10.3 triple=$arch-unknown-freebsd10 sysroot=/usr/local/$triple hide_output() { set +x local on_err=" echo ERROR: An error was encountered with the build. cat /tmp/build.log exit 1 " trap "$on_err" ERR bash -c "while true; do sleep 30; echo $(date) - building ...; done" & local ping_loop_pid=$! $@ &> /tmp/build.log trap - ERR kill $ping_loop_pid set -x } # First up, build binutils mkdir binutils cd binutils curl https://ftp.gnu.org/gnu/binutils/binutils-${binutils_version}.tar.bz2 | tar xjf - mkdir binutils-build cd binutils-build hide_output ../binutils-${binutils_version}/configure  --target="$triple" --with-sysroot="$sysroot" hide_output make -j"$(getconf _NPROCESSORS_ONLN)" hide_output make install cd ../.. rm -rf binutils # Next, download the FreeBSD libraries and header files mkdir -p "$sysroot" case $arch in (x86_64) freebsd_arch=amd64 ;; (i686) freebsd_arch=i386 ;; esac files_to_extract=( "./usr/include" "./usr/lib/*crt*.o" ) # Try to unpack only the libraries the build needs, to save space. for lib in c cxxrt gcc_s m thr util; do files_to_extract=("${files_to_extract[@]}" "./lib/lib${lib}.*" "./usr/lib/lib${lib}.*") done for lib in c++ c_nonshared compiler_rt execinfo gcc pthread rt ssp_nonshared; do files_to_extract=("${files_to_extract[@]}" "./usr/lib/lib${lib}.*") done URL=https://download.freebsd.org/ftp/releases/${freebsd_arch}/${freebsd_version}-RELEASE/base.txz curl "$URL" | tar xJf - -C "$sysroot" --wildcards "${files_to_extract[@]}" # Fix up absolute symlinks from the system image.  This can be removed # for FreeBSD 11.  (If there's an easy way to make them relative # symlinks instead, feel free to change this.) set +x find "$sysroot" -type l | while read symlink_path; do symlink_target=$(readlink "$symlink_path") case $symlink_target in (/*) echo "Fixing symlink ${symlink_path} -> ${sysroot}${symlink_target}" >&2 ln -nfs "${sysroot}${symlink_target}" "${symlink_path}" ;; esac done set -x # Clang can do cross-builds out of the box, if we give it the right # flags.  (The local binutils seem to work, but they set the ELF # header "OS/ABI" (EI_OSABI) field to SysV rather than FreeBSD, so # there might be other problems.) # # The --target option is last because the cross-build of LLVM uses # --target without an OS version ("-freebsd" vs. "-freebsd10").  This # makes Clang default to libstdc++ (which no longer exists), and also # controls other features, like GNU-style symbol table hashing and # anything predicated on the version number in the __FreeBSD__ # preprocessor macro. for tool in clang clang++; do tool_path=/usr/local/bin/${triple}-${tool} cat > "$tool_path" <<EOF #!/bin/sh exec $tool --sysroot=$sysroot --prefix=${sysroot}/bin "$@" --target=$triple EOF chmod +x "$tool_path" done </ins>


Question:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

let stdcppname = if target.contains("openbsd") { // llvm-config on OpenBSD doesn't mention stdlib=libc++ "c++" <ins> } else if target.contains("freebsd") { "c++" </ins> } else if target.contains("netbsd") && llvm_static_stdcpp.is_some() { // NetBSD uses a separate library when relocation is required "stdc++_pic"


Question:
"Cousins" of borrowed union sub-fields (and their further children) are not marked as borrowed.
This is , though I sort of thought we had tried to fix this.
I'm tagging this as WG-compiler-nll; I think it's something we should fix there.
For the sake of potential testsuite additions: this also should not compile with a simultaneous borrow of and .
I'll take a look at this one.
I'm not really sure what the bug is here, but I can explain what I think should be happening. This function: is responsible for determining when two values overlap. I expect us to say that two fields from a union are always considered to potentially overlap. In this case, and would be considered to overlap. Specifically, comparing those two fields would return : This is the code that I think should be responsible for doing that: It already looks a little fishy to me; in particular, it is returning if is a union, but I guess it should be equally true if is a union. Anyway, something here seems to be going awry!
So it seems like I forgot about how smart the compiler is now. This version of the test does error, as expected:
I think the policy is that we will keep this bug open, but file it under
(Since it is only fixed when NLL is enabled)
should this be ?
Note that to get an NLL test failure, you have to use after declaring :
NLL (migrate mode) is enabled in all editions as of PR . The only policy question is that, under migrate mode, we only emit a warning on this (unsound) test case. Therefore, I am not 100% sure whether we should close this until that warning has been turned into a hard-error under our (still in development) future-compatibility lint policy.

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![allow(unused)] #![feature(nll)] #[derive(Clone, Copy, Default)] struct S { a: u8, b: u8, } #[derive(Clone, Copy, Default)] struct Z { c: u8, d: u8, } union U { s: S, z: Z, } fn main() { unsafe { let mut u = U { s: Default::default() }; let mref = &mut u.s.a; *mref = 22; let nref = &u.z.c; //~^ ERROR cannot borrow `u.z.c` as immutable because it is also borrowed as mutable [E0502] println!("{} {}", mref, nref) //~^ ERROR cannot borrow `u.s.a` as mutable because it is also borrowed as immutable [E0502] } } </ins>


Question:
"Cousins" of borrowed union sub-fields (and their further children) are not marked as borrowed.
This is , though I sort of thought we had tried to fix this.
I'm tagging this as WG-compiler-nll; I think it's something we should fix there.
For the sake of potential testsuite additions: this also should not compile with a simultaneous borrow of and .
I'll take a look at this one.
I'm not really sure what the bug is here, but I can explain what I think should be happening. This function: is responsible for determining when two values overlap. I expect us to say that two fields from a union are always considered to potentially overlap. In this case, and would be considered to overlap. Specifically, comparing those two fields would return : This is the code that I think should be responsible for doing that: It already looks a little fishy to me; in particular, it is returning if is a union, but I guess it should be equally true if is a union. Anyway, something here seems to be going awry!
So it seems like I forgot about how smart the compiler is now. This version of the test does error, as expected:
I think the policy is that we will keep this bug open, but file it under
(Since it is only fixed when NLL is enabled)
should this be ?
Note that to get an NLL test failure, you have to use after declaring :
NLL (migrate mode) is enabled in all editions as of PR . The only policy question is that, under migrate mode, we only emit a warning on this (unsound) test case. Therefore, I am not 100% sure whether we should close this until that warning has been turned into a hard-error under our (still in development) future-compatibility lint policy.

<ins> error[E0502]: cannot borrow `u.z.c` as immutable because it is also borrowed as mutable --> $DIR/issue-45157.rs:37:20 | 34 |         let mref = &mut u.s.a; |                    ---------- mutable borrow occurs here ... 37 |         let nref = &u.z.c; |                    ^^^^^^ immutable borrow occurs here error[E0502]: cannot borrow `u.s.a` as mutable because it is also borrowed as immutable --> $DIR/issue-45157.rs:39:27 | 37 |         let nref = &u.z.c; |                    ------ immutable borrow occurs here 38 |         //~^ ERROR cannot borrow `u.z.c` as immutable because it is also borrowed as mutable [E0502] 39 |         println!("{} {}", mref, nref) |                           ^^^^ mutable borrow occurs here error: aborting due to 2 previous errors </ins>


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

[[package]] name = "bitflags" <del> version = "0.8.2" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "bitflags" </del> version = "0.9.1" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

[[package]] name = "pulldown-cmark" <del> version = "0.0.14" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "pulldown-cmark" </del> version = "0.0.15" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

"env_logger 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", "html-diff 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)", <del> "pulldown-cmark 0.0.14 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "pulldown-cmark 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

"checksum backtrace 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "99f2ce94e22b8e664d95c57fff45b98a966c2252b60691d0b7aeeccd88d70983" "checksum backtrace-sys 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "c63ea141ef8fdb10409d0f5daf30ac51f84ef43bff66f16627773d2a292cd189" "checksum bitflags 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "aad18937a628ec6abcd26d1489012cc0e18c21798210f491af69ded9b881106d" <del> "checksum bitflags 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)" = "1370e9fc2a6ae53aea8b7a5110edbd08836ed87c88736dfabccade1c2b44bff4" </del> "checksum bitflags 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)" = "4efd02e230a02e18f92fc2735f44597385ed02ad8f831e7c1c1156ee5e1ab3a5" "checksum bitflags 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f5cde24d1b2e2216a726368b2363a273739c91f4e3eb4e0dd12d672d396ad989" "checksum bufstream 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "f2f382711e76b9de6c744cc00d0497baba02fb00a787f088c879f01d09468e32"


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

"checksum precomputed-hash 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "cdf1fc3616b3ef726a847f2cd2388c646ef6a1f1ba4835c2629004da48184150" "checksum procedural-masquerade 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "c93cdc1fb30af9ddf3debc4afbdb0f35126cbd99daa229dd76cdd5349b41d989" "checksum psapi-sys 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "abcd5d1a07d360e29727f757a9decb3ce8bc6e0efa8969cfaad669a8317a2478" <del> "checksum pulldown-cmark 0.0.14 (registry+https://github.com/rust-lang/crates.io-index)" = "d9ab1e588ef8efd702c7ed9d2bd774db5e6f4d878bb5a1a9f371828fbdff6973" </del> "checksum pulldown-cmark 0.0.15 (registry+https://github.com/rust-lang/crates.io-index)" = "378e941dbd392c101f2cb88097fa4d7167bc421d4b88de3ff7dbee503bc3233b" "checksum pulldown-cmark 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "a656fdb8b6848f896df5e478a0eb9083681663e37dcb77dd16981ff65329fe8b" "checksum quick-error 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "eda5fe9b71976e62bc81b781206aaa076401769b2143379d3eb2118388babac4"


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

[dependencies] env_logger = { version = "0.4", default-features = false } log = "0.3" <del> pulldown-cmark = { version = "0.0.14", default-features = false } </del> <ins> pulldown-cmark = { version = "0.1.0", default-features = false } </ins> html-diff = "0.0.4" [build-dependencies]


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

match self.inner.next() { Some(Event::FootnoteReference(ref reference)) => { let entry = self.get_entry(&reference);  let reference = format!("{0}   let reference = format!("{0}  ", (*entry).1); return Some(Event::Html(reference.into()));


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

v.sort_by(|a, b| a.1.cmp(&b.1)); let mut ret = String::from("

"); for (mut content, id) in v {  write!(ret, "
", id).unwrap();   write!(ret, "
", id).unwrap();  let mut is_paragraph = false; if let Some(&Event::End(Tag::Paragraph)) = content.last() { content.pop();


Question:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

} html::push_html(&mut ret, content.into_iter()); write!(ret,  " ↩",   " ↩",  id).unwrap(); if is_paragraph { ret.push_str("
");


Question:
Hey, I'm curious about the . From what I understand: this works because Path is a single member struct containing only the type it's being reinterpreted as. My original question on #rust IRC was: Is this always guaranteed to be correct (in Rust) in terms of memory layout? The discussion seemed to hint at that this is in fact not a guarantee, but that std is in a unique position being developed in concert with the language and any future breakage would be patched when it occurs. I would love some clarification if this usage is correct or to what degree it is not. I'd also suggest we add clarification around this case with comments or support functions to aid future spelunking into std.
No, strictly speaking, this is not safe without .
excellent, thank you! The seems to indicate things going slowly. Adding a comment might still be a good idea for now. Reading the RFC, it mentions at least ARM64 where there might be layout differences. But according to , std shows up as supported as a Tier 2 platform. This implies that at least for now, this pattern in this instance () works. Is this correct?
That ARM64 issue seems to be related to calling convention, not memory layout, so it's not an issue here.
This is my understanding as well. I believe it is safe with either repr(transparent) or repr(C), the latter of which is stable. The  crate is a generalization of this safe cast.

} // See note at the top of this module to understand why these are used: <ins> // // These casts are safe as OsStr is internally a wrapper around [u8] on all // platforms. // // Note that currently this relies on the special knowledge that libstd has; // these types are single-element structs but are not marked repr(transparent) // or repr(C) which would make these casts allowable outside std. </ins> fn os_str_as_u8_slice(s: &OsStr) -> &[u8] { unsafe { &*(s as *const OsStr as *const [u8]) } }


Question: The benchmarks for LinearMap and TreeMap should just be using the Map trait, but I encountered a strange borrow checking issue: diff: error: This seems like a borrowck bug, but I'm not sure. The same issue occurs when trying to work around it with a trait like with a method.

<del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2013 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: The benchmarks for LinearMap and TreeMap should just be using the Map trait, but I encountered a strange borrow checking issue: diff: error: This seems like a borrowck bug, but I'm not sure. The same issue occurs when trying to work around it with a trait like with a method.

// except according to those terms. extern mod std; <del> use std::oldmap; use std::treemap::TreeMap; use core::hashmap::linear::*; use core::io::WriterUtil; struct Results { sequential_ints: float, random_ints: float, delete_ints: float, sequential_strings: float, random_strings: float, delete_strings: float } fn timed(result: &mut float, op: &fn()) { let start = std::time::precise_time_s(); op(); let end = std::time::precise_time_s(); *result = (end - start); </del> <ins> use core::io; use std::time; use std::treemap::TreeMap; use core::hashmap::linear::{LinearMap, LinearSet}; use core::trie::TrieMap; fn timed(label: &str, f: &fn()) { let start = time::precise_time_s(); f(); let end = time::precise_time_s(); io::println(fmt!("  %s: %f", label, end - start)); </ins> } <del> fn old_int_benchmarks(rng: @rand::Rng, num_keys: uint, results: &mut Results) { { let map = oldmap::HashMap(); do timed(&mut results.sequential_ints) { for uint::range(0, num_keys) |i| { map.insert(i, i+1); } </del> <ins> fn ascending<M: Map<uint, uint>>(map: &mut M, n_keys: uint) { io::println(" Ascending integers:"); </ins> <del> for uint::range(0, num_keys) |i| { fail_unless!(map.get(&i) == i+1); } </del> <ins> do timed("insert") { for uint::range(0, n_keys) |i| { map.insert(i, i + 1); </ins> } } <del> { let map = oldmap::HashMap(); do timed(&mut results.random_ints) { for uint::range(0, num_keys) |i| { map.insert(rng.next() as uint, i); } </del> <ins> do timed("search") { for uint::range(0, n_keys) |i| { fail_unless!(map.find(&i).unwrap() == &(i + 1)); </ins> } } <del> { let map = oldmap::HashMap(); for uint::range(0, num_keys) |i| { map.insert(i, i);; } do timed(&mut results.delete_ints) { for uint::range(0, num_keys) |i| { fail_unless!(map.remove(&i)); } </del> <ins> do timed("remove") { for uint::range(0, n_keys) |i| { fail_unless!(map.remove(&i)); </ins> } } } <del> fn old_str_benchmarks(rng: @rand::Rng, num_keys: uint, results: &mut Results) { { let map = oldmap::HashMap(); do timed(&mut results.sequential_strings) { for uint::range(0, num_keys) |i| { let s = uint::to_str(i); map.insert(s, i); } </del> <ins> fn descending<M: Map<uint, uint>>(map: &mut M, n_keys: uint) { io::println(" Descending integers:"); </ins> <del> for uint::range(0, num_keys) |i| { let s = uint::to_str(i); fail_unless!(map.get(&s) == i); } </del> <ins> do timed("insert") { for uint::range(0, n_keys) |i| { map.insert(i, i + 1); </ins> } } <del> { let map = oldmap::HashMap(); do timed(&mut results.random_strings) { for uint::range(0, num_keys) |i| { let s = uint::to_str(rng.next() as uint); map.insert(s, i); } </del> <ins> do timed("search") { for uint::range(0, n_keys) |i| { fail_unless!(map.find(&i).unwrap() == &(i + 1)); </ins> } } <del> { let map = oldmap::HashMap(); for uint::range(0, num_keys) |i| { map.insert(uint::to_str(i), i); } do timed(&mut results.delete_strings) { for uint::range(0, num_keys) |i| { fail_unless!(map.remove(&uint::to_str(i))); } </del> <ins> do timed("remove") { for uint::range(0, n_keys) |i| { fail_unless!(map.remove(&i)); </ins> } } } <del> fn linear_int_benchmarks(rng: @rand::Rng, num_keys: uint, results: &mut Results) { { let mut map = LinearMap::new(); do timed(&mut results.sequential_ints) { for uint::range(0, num_keys) |i| { map.insert(i, i+1); } </del> <ins> fn vector<M: Map<uint, uint>>(map: &mut M, n_keys: uint, dist: &[uint]) { </ins> <del> for uint::range(0, num_keys) |i| { fail_unless!(map.find(&i).unwrap() == &(i+1)); } </del> <ins> do timed("insert") { for uint::range(0, n_keys) |i| { map.insert(dist[i], i + 1); </ins> } } <del> { let mut map = LinearMap::new(); do timed(&mut results.random_ints) { for uint::range(0, num_keys) |i| { map.insert(rng.next() as uint, i); } </del> <ins> do timed("search") { for uint::range(0, n_keys) |i| { fail_unless!(map.find(&dist[i]).unwrap() == &(i + 1)); </ins> } } <del> { let mut map = LinearMap::new(); for uint::range(0, num_keys) |i| { map.insert(i, i);; } do timed(&mut results.delete_ints) { for uint::range(0, num_keys) |i| { fail_unless!(map.remove(&i)); } </del> <ins> do timed("remove") { for uint::range(0, n_keys) |i| { fail_unless!(map.remove(&dist[i])); </ins> } } } <del> fn linear_str_benchmarks(rng: @rand::Rng, num_keys: uint, results: &mut Results) { { let mut map = LinearMap::new(); do timed(&mut results.sequential_strings) { for uint::range(0, num_keys) |i| { let s = uint::to_str(i); map.insert(s, i); } for uint::range(0, num_keys) |i| { let s = uint::to_str(i); fail_unless!(map.find(&s).unwrap() == &i); } </del> <ins> fn main() { let args = os::args(); let n_keys = { if args.len() == 2 { uint::from_str(args[1]).get() } else { 1000000 </ins> } <del> } </del> <ins> }; </ins> <del> { let mut map = LinearMap::new(); do timed(&mut results.random_strings) { for uint::range(0, num_keys) |i| { let s = uint::to_str(rng.next() as uint); map.insert(s, i); } } } </del> <ins> let mut rand = vec::with_capacity(n_keys); </ins> { <del> let mut map = LinearMap::new(); for uint::range(0, num_keys) |i| { map.insert(uint::to_str(i), i); } do timed(&mut results.delete_strings) { for uint::range(0, num_keys) |i| { fail_unless!(map.remove(&uint::to_str(i))); </del> <ins> let rng = core::rand::seeded_rng([1, 1, 1, 1, 1, 1, 1]); let mut set = LinearSet::new(); while set.len() != n_keys { let next = rng.next() as uint; if set.insert(next) { rand.push(next); </ins> } } } <del> } fn tree_int_benchmarks(rng: @rand::Rng, num_keys: uint, results: &mut Results) { { let mut map = TreeMap::new(); do timed(&mut results.sequential_ints) { for uint::range(0, num_keys) |i| { map.insert(i, i+1); } </del> <ins> io::println(fmt!("%? keys", n_keys)); </ins> <del> for uint::range(0, num_keys) |i| { fail_unless!(map.find(&i).unwrap() == &(i+1)); } } } </del> <ins> io::println("nTreeMap:"); </ins> { <del> let mut map = TreeMap::new(); do timed(&mut results.random_ints) { for uint::range(0, num_keys) |i| { map.insert(rng.next() as uint, i); } } </del> <ins> let mut map = TreeMap::new::<uint, uint>(); ascending(&mut map, n_keys); </ins> } { <del> let mut map = TreeMap::new(); for uint::range(0, num_keys) |i| { map.insert(i, i);; } do timed(&mut results.delete_ints) { for uint::range(0, num_keys) |i| { fail_unless!(map.remove(&i)); } } </del> <ins> let mut map = TreeMap::new::<uint, uint>(); descending(&mut map, n_keys); </ins> } <del> } fn tree_str_benchmarks(rng: @rand::Rng, num_keys: uint, results: &mut Results) { </del> { <del> let mut map = TreeMap::new(); do timed(&mut results.sequential_strings) { for uint::range(0, num_keys) |i| { let s = uint::to_str(i); map.insert(s, i); } for uint::range(0, num_keys) |i| { let s = uint::to_str(i); fail_unless!(map.find(&s).unwrap() == &i); } } </del> <ins> io::println(" Random integers:"); let mut map = TreeMap::new::<uint, uint>(); vector(&mut map, n_keys, rand); </ins> } <ins> io::println("nLinearMap:"); </ins> { <del> let mut map = TreeMap::new(); do timed(&mut results.random_strings) { for uint::range(0, num_keys) |i| { let s = uint::to_str(rng.next() as uint); map.insert(s, i); } } </del> <ins> let mut map = LinearMap::new::<uint, uint>(); ascending(&mut map, n_keys); </ins> } { <del> let mut map = TreeMap::new(); for uint::range(0, num_keys) |i| { map.insert(uint::to_str(i), i); } do timed(&mut results.delete_strings) { for uint::range(0, num_keys) |i| { fail_unless!(map.remove(&uint::to_str(i))); } } </del> <ins> let mut map = LinearMap::new::<uint, uint>(); descending(&mut map, n_keys); </ins> } <del> } fn write_header(header: &str) { io::stdout().write_str(header); io::stdout().write_str("n"); } fn write_row(label: &str, value: float) { io::stdout().write_str(fmt!("%30s %f sn", label, value)); } fn write_results(label: &str, results: &Results) { write_header(label); write_row("sequential_ints", results.sequential_ints); write_row("random_ints", results.random_ints); write_row("delete_ints", results.delete_ints); write_row("sequential_strings", results.sequential_strings); write_row("random_strings", results.random_strings); write_row("delete_strings", results.delete_strings); } fn empty_results() -> Results { Results { sequential_ints: 0f, random_ints: 0f, delete_ints: 0f, sequential_strings: 0f, random_strings: 0f, delete_strings: 0f, </del> <ins> { io::println(" Random integers:"); let mut map = LinearMap::new::<uint, uint>(); vector(&mut map, n_keys, rand); </ins> } <del> } fn main() { let args = os::args(); let num_keys = { if args.len() == 2 { uint::from_str(args[1]).get() } else { 100 // woefully inadequate for any real measurement } }; let seed = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; </del> <ins> io::println("nTrieMap:"); </ins> { <del> let rng = rand::seeded_rng(seed); let mut results = empty_results(); old_int_benchmarks(rng, num_keys, &mut results); old_str_benchmarks(rng, num_keys, &mut results); write_results("std::oldmap::HashMap", &results); </del> <ins> let mut map = TrieMap::new::<uint>(); ascending(&mut map, n_keys); </ins> } { <del> let rng = rand::seeded_rng(seed); let mut results = empty_results(); linear_int_benchmarks(rng, num_keys, &mut results); linear_str_benchmarks(rng, num_keys, &mut results); write_results("core::hashmap::linear::LinearMap", &results); </del> <ins> let mut map = TrieMap::new::<uint>(); descending(&mut map, n_keys); </ins> } { <del> let rng = rand::seeded_rng(seed); let mut results = empty_results(); tree_int_benchmarks(rng, num_keys, &mut results); tree_str_benchmarks(rng, num_keys, &mut results); write_results("std::treemap::TreeMap", &results); </del> <ins> io::println(" Random integers:"); let mut map = TrieMap::new::<uint>(); vector(&mut map, n_keys, rand); </ins> } }


Question:
Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.

/// Simple usage: /// /// ``` <del> /// #![feature(box_leak)] /// </del> /// fn main() { ///     let x = Box::new(41); ///     let static_ref: &'static mut usize = Box::leak(x);


Question:
Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.

/// Unsized data: /// /// ``` <del> /// #![feature(box_leak)] /// </del> /// fn main() { ///     let x = vec![1, 2, 3].into_boxed_slice(); ///     let static_ref = Box::leak(x);


Question:
Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.

///     assert_eq!(*static_ref, [4, 2, 3]); /// } /// ``` <del> #[unstable(feature = "box_leak", reason = "needs an FCP to stabilize", issue = "46179")] </del> <ins> #[stable(feature = "box_leak", since = "1.26.0")] </ins> #[inline] pub fn leak<'a>(b: Box<T>) -> &'a mut T where


Question:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

return; } <ins> let (_, line_hi, col_hi) = match ctx.byte_pos_to_line_and_col(span.hi) { Some(pos) => pos, None => { Hash::hash(&TAG_INVALID_SPAN, hasher); span.ctxt.hash_stable(ctx, hasher); return; } }; </ins> Hash::hash(&TAG_VALID_SPAN, hasher); // We truncate the stable ID hash and line and column numbers. The chances // of causing a collision this way should be minimal. Hash::hash(&(file_lo.name_hash as u64), hasher); <del> let col = (col_lo.0 as u64) & 0xFF; let line = ((line_lo as u64) & 0xFF_FF_FF) << 8; let len = ((span.hi - span.lo).0 as u64) << 32; let line_col_len = col | line | len; Hash::hash(&line_col_len, hasher); </del> <ins> // Hash both the length and the end location (line/column) of a span. If we // hash only the length, for example, then two otherwise equal spans with // different end locations will have the same hash. This can cause a problem // during incremental compilation wherein a previous result for a query that // depends on the end location of a span will be incorrectly reused when the // end location of the span it depends on has changed (see issue #74890). A // similar analysis applies if some query depends specifically on the length // of the span, but we only hash the end location. So hash both. let col_lo_trunc = (col_lo.0 as u64) & 0xFF; let line_lo_trunc = ((line_lo as u64) & 0xFF_FF_FF) << 8; let col_hi_trunc = (col_hi.0 as u64) & 0xFF << 32; let line_hi_trunc = ((line_hi as u64) & 0xFF_FF_FF) << 40; let col_line = col_lo_trunc | line_lo_trunc | col_hi_trunc | line_hi_trunc; let len = (span.hi - span.lo).0; Hash::hash(&col_line, hasher); Hash::hash(&len, hasher); </ins> span.ctxt.hash_stable(ctx, hasher); } }


Question:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

<ins> include ../../run-make-fulldeps/tools.mk # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) # Tests that we don't ICE during incremental compilation after modifying a # function span such that its previous end line exceeds the number of lines # in the new file, but its start line/column and length remain the same. SRC=$(TMPDIR)/src INCR=$(TMPDIR)/incr all: mkdir $(SRC) mkdir $(INCR) cp a.rs $(SRC)/main.rs $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs cp b.rs $(SRC)/main.rs $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs </ins>


Question:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

<ins> fn main() { // foo must be used. foo(); } // For this test to operate correctly, foo's body must start on exactly the same // line and column and have the exact same length in bytes in a.rs and b.rs. In // a.rs, the body must end on a line number which does not exist in b.rs. // Basically, avoid modifying this file, including adding or removing whitespace! fn foo() { assert_eq!(1, 1); } </ins>


Question:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

<ins> fn main() { // foo must be used. foo(); } // For this test to operate correctly, foo's body must start on exactly the same // line and column and have the exact same length in bytes in a.rs and b.rs. In // a.rs, the body must end on a line number which does not exist in b.rs. // Basically, avoid modifying this file, including adding or removing whitespace! fn foo() { assert_eq!(1, 1);//// } </ins>


Question:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

include ../../run-make-fulldeps/tools.mk <ins> # FIXME https://github.com/rust-lang/rust/issues/78911 </ins> # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) all: foo


Question: this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

let (span, e) = self.interpolated_or_expr_span(e)?; (lo.to(span), ExprKind::Box(e)) } <del> _ => return self.parse_dot_or_call_expr(Some(attrs)) </del> <ins> token::Ident(..) if self.token.is_ident_named("not") => { // `not` is just an ordinary identifier in Rust-the-language, // but as `rustc`-the-compiler, we can issue clever diagnostics // for confused users who really want to say `!` let token_cannot_continue_expr = |t: &token::Token| match *t { // These tokens can start an expression after `!`, but // can't continue an expression after an ident token::Ident(ident, is_raw) => token::ident_can_begin_expr(ident, is_raw), token::Literal(..) | token::Pound => true, token::Interpolated(ref nt) => match nt.0 { token::NtIdent(..) | token::NtExpr(..) | token::NtBlock(..) | token::NtPath(..) => true, _ => false, }, _ => false }; let cannot_continue_expr = self.look_ahead(1, token_cannot_continue_expr); if cannot_continue_expr { self.bump(); // Emit the error ... let mut err = self.diagnostic() .struct_span_err(self.span, &format!("unexpected {} after identifier", self.this_token_descr())); // span the `not` plus trailing whitespace to avoid // trailing whitespace after the `!` in our suggestion let to_replace = self.sess.codemap() .span_until_non_whitespace(lo.to(self.span)); err.span_suggestion_short(to_replace, "use `!` to perform logical negation", "!".to_owned()); err.emit(); // —and recover! (just as if we were in the block // for the `token::Not` arm) let e = self.parse_prefix_expr(None); let (span, e) = self.interpolated_or_expr_span(e)?; (lo.to(span), self.mk_unary(UnOp::Not, e)) } else { return self.parse_dot_or_call_expr(Some(attrs)); } } _ => { return self.parse_dot_or_call_expr(Some(attrs)); } </ins> }; return Ok(self.mk_expr(lo.to(hi), ex, attrs)); }


Question: this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

// Which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { <ins> if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) { // if the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right return Err(e); } </ins> let mut stmt_span = stmt.span; // expand the span to include the semicolon, if it exists if self.eat(&token::Semi) {


Question: this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

} } <del> fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool { </del> <ins> pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool { </ins> let ident_token: Token = Ident(ident, is_raw); !ident_token.is_reserved_ident() ||


Question: this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

self.lifetime().is_some() } <ins> /// Returns `true` if the token is a identifier whose name is the given /// string slice. pub fn is_ident_named(&self, name: &str) -> bool { match self.ident() { Some((ident, _)) => ident.name.as_str() == name, None => false } } </ins> /// Returns `true` if the token is a documentation comment. pub fn is_doc_comment(&self) -> bool { match *self {


Question: this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

<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. fn gratitude() { let for_you = false; if not for_you { //~^ ERROR unexpected `for_you` after identifier println!("I couldn't"); } } fn qualification() { let the_worst = true; while not the_worst { //~^ ERROR unexpected `the_worst` after identifier println!("still pretty bad"); } } fn should_we() { let not = true; if not  // lack of braces is [sic] println!("Then when?"); //~^ ERROR expected `{`, found `; //~| ERROR unexpected `println` after identifier } fn sleepy() { let resource = not 2; //~^ ERROR unexpected `2` after identifier } fn main() { let be_smothered_out_before = true; let young_souls = not be_smothered_out_before; //~^ ERROR unexpected `be_smothered_out_before` after identifier } </ins>


Question: this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

<ins> error: unexpected `for_you` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:13:12 | LL |     if not for_you { |        ----^^^^^^^ |        | |        help: use `!` to perform logical negation error: unexpected `the_worst` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:21:15 | LL |     while not the_worst { |           ----^^^^^^^^^ |           | |           help: use `!` to perform logical negation error: unexpected `println` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:30:9 | LL |     if not  // lack of braces is [sic] |        ----- help: use `!` to perform logical negation LL |         println!("Then when?"); |         ^^^^^^^ error: expected `{`, found `;` --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:30:31 | LL |     if not  // lack of braces is [sic] |     -- this `if` statement has a condition, but no block LL |         println!("Then when?"); |                               ^ error: unexpected `2` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:36:24 | LL |     let resource = not 2; |                    ----^ |                    | |                    help: use `!` to perform logical negation error: unexpected `be_smothered_out_before` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:42:27 | LL |     let young_souls = not be_smothered_out_before; |                       ----^^^^^^^^^^^^^^^^^^^^^^^ |                       | |                       help: use `!` to perform logical negation error: aborting due to 6 previous errors </ins>