Question:
Info located at: Looking at the source code in libcollections there doesn't seem to be such a method alltogether.
This would be fixed by The new way is

<del> % The Rust Threads and Communication Guide **NOTE** This guide is badly out of date and needs to be rewritten. # Introduction Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs. Threads provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to `panic!()`, an assertion failure, or another invalid operation, the runtime system destroys the entire thread. Unlike in languages such as Java and C++, there is no way to `catch` an exception. Instead, threads may monitor each other to see if they panic. Threads use Rust's type system to provide strong memory safety guarantees.  In particular, the type system guarantees that threads cannot induce a data race from shared mutable state. # Basics At its simplest, creating a thread is a matter of calling the `spawn` function with a closure argument. `spawn` executes the closure in the new thread. ```{rust,ignore} # use std::thread::spawn; // Print something profound in a different thread using a named function fn print_message() { println!("I am running in a different thread!"); } spawn(print_message); // Alternatively, use a `move ||` expression instead of a named function. // `||` expressions evaluate to an unnamed closure. The `move` keyword // indicates that the closure should take ownership of any variables it // touches. spawn(move || println!("I am also running in a different thread!")); ``` In Rust, a thread is not a concept that appears in the language semantics. Instead, Rust's type system provides all the tools necessary to implement safe concurrency: particularly, ownership. The language leaves the implementation details to the standard library. The `spawn` function has the type signature: `fn spawn<F:FnOnce()+Send>(f: F)`.  This indicates that it takes as argument a closure (of type `F`) that it will run exactly once. This closure is limited to capturing `Send`-able data from its environment (that is, data which is deeply owned). Limiting the closure to `Send` ensures that `spawn` can safely move the entire closure and all its associated state into an entirely different thread for execution. ```rust use std::thread::Thread; fn generate_thread_number() -> i32 { 4 } // a very simple generation // Generate some state locally let child_thread_number = generate_thread_number(); Thread::spawn(move || { // Capture it in the remote thread. The `move` keyword indicates // that this closure should move `child_thread_number` into its // environment, rather than capturing a reference into the // enclosing stack frame. println!("I am child number {}", child_thread_number); }); ``` ## Communication Now that we have spawned a new thread, it would be nice if we could communicate with it. For this, we use *channels*. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages. The simplest way to create a channel is to use the `channel` function to create a `(Sender, Receiver)` pair. In Rust parlance, a *sender* is a sending endpoint of a channel, and a *receiver* is the receiving endpoint. Consider the following example of calculating two results concurrently: ```rust use std::thread::Thread; use std::sync::mpsc; let (tx, rx): (mpsc::Sender<u32>, mpsc::Receiver<u32>) = mpsc::channel(); Thread::spawn(move || { let result = some_expensive_computation(); tx.send(result); }); some_other_expensive_computation(); let result = rx.recv(); fn some_expensive_computation() -> u32 { 42 } // very expensive ;) fn some_other_expensive_computation() {}      // even more so ``` Let's examine this example in detail. First, the `let` statement creates a stream for sending and receiving integers (the left-hand side of the `let`, `(tx, rx)`, is an example of a destructuring let: the pattern separates a tuple into its component parts). ```rust # use std::sync::mpsc; let (tx, rx): (mpsc::Sender<u32>, mpsc::Receiver<u32>) = mpsc::channel(); ``` The child thread will use the sender to send data to the parent thread, which will wait to receive the data on the receiver. The next statement spawns the child thread. ```rust # use std::thread::Thread; # use std::sync::mpsc; # fn some_expensive_computation() -> u32 { 42 } # let (tx, rx) = mpsc::channel(); Thread::spawn(move || { let result = some_expensive_computation(); tx.send(result); }); ``` Notice that the creation of the thread closure transfers `tx` to the child thread implicitly: the closure captures `tx` in its environment. Both `Sender` and `Receiver` are sendable types and may be captured into threads or otherwise transferred between them. In the example, the child thread runs an expensive computation, then sends the result over the captured channel. Finally, the parent continues with some other expensive computation, then waits for the child's result to arrive on the receiver: ```rust # use std::sync::mpsc; # fn some_other_expensive_computation() {} # let (tx, rx) = mpsc::channel::<u32>(); # tx.send(0); some_other_expensive_computation(); let result = rx.recv(); ``` The `Sender` and `Receiver` pair created by `channel` enables efficient communication between a single sender and a single receiver, but multiple senders cannot use a single `Sender` value, and multiple receivers cannot use a single `Receiver` value.  What if our example needed to compute multiple results across a number of threads? The following program is ill-typed: ```{rust,ignore} # use std::sync::mpsc; # fn some_expensive_computation() -> u32 { 42 } let (tx, rx) = mpsc::channel(); spawn(move || { tx.send(some_expensive_computation()); }); // ERROR! The previous spawn statement already owns the sender, // so the compiler will not allow it to be captured again spawn(move || { tx.send(some_expensive_computation()); }); ``` Instead we can clone the `tx`, which allows for multiple senders. ```rust use std::thread::Thread; use std::sync::mpsc; let (tx, rx) = mpsc::channel(); for init_val in 0 .. 3 { // Create a new channel handle to distribute to the child thread let child_tx = tx.clone(); Thread::spawn(move || { child_tx.send(some_expensive_computation(init_val)); }); } let result = rx.recv().unwrap() + rx.recv().unwrap() + rx.recv().unwrap(); # fn some_expensive_computation(_i: i32) -> i32 { 42 } ``` Cloning a `Sender` produces a new handle to the same channel, allowing multiple threads to send data to a single receiver. It upgrades the channel internally in order to allow this functionality, which means that channels that are not cloned can avoid the overhead required to handle multiple senders. But this fact has no bearing on the channel's usage: the upgrade is transparent. Note that the above cloning example is somewhat contrived since you could also simply use three `Sender` pairs, but it serves to illustrate the point. For reference, written with multiple streams, it might look like the example below. ```rust use std::thread::Thread; use std::sync::mpsc; // Create a vector of ports, one for each child thread let rxs = (0 .. 3).map(|&:init_val| { let (tx, rx) = mpsc::channel(); Thread::spawn(move || { tx.send(some_expensive_computation(init_val)); }); rx }).collect::<Vec<_>>(); // Wait on each port, accumulating the results let result = rxs.iter().fold(0, |&:accum, rx| accum + rx.recv().unwrap() ); # fn some_expensive_computation(_i: i32) -> i32 { 42 } ``` ## Backgrounding computations: Futures With `sync::Future`, rust has a mechanism for requesting a computation and getting the result later. The basic example below illustrates this. ```{rust,ignore} # #![allow(deprecated)] use std::sync::Future; # fn main() { # fn make_a_sandwich() {}; fn fib(n: u64) -> u64 { // lengthy computation returning an 64 12586269025 } let mut delayed_fib = Future::spawn(move || fib(50)); make_a_sandwich(); println!("fib(50) = {}", delayed_fib.get()) # } ``` The call to `future::spawn` immediately returns a `future` object regardless of how long it takes to run `fib(50)`. You can then make yourself a sandwich while the computation of `fib` is running. The result of the execution of the method is obtained by calling `get` on the future. This call will block until the value is available (*i.e.* the computation is complete). Note that the future needs to be mutable so that it can save the result for next time `get` is called. Here is another example showing how futures allow you to background computations. The workload will be distributed on the available cores. ```{rust,ignore} # #![allow(deprecated)] # use std::num::Float; # use std::sync::Future; fn partial_sum(start: u64) -> f64 { let mut local_sum = 0f64; for num in range(start*100000, (start+1)*100000) { local_sum += (num as f64 + 1.0).powf(-2.0); } local_sum } fn main() { let mut futures = Vec::from_fn(200, |ind| Future::spawn(move || partial_sum(ind))); let mut final_res = 0f64; for ft in futures.iter_mut()  { final_res += ft.get(); } println!("π^2/6 is not far from : {}", final_res); } ``` ## Sharing without copying: Arc To share data between threads, a first approach would be to only use channel as we have seen previously. A copy of the data to share would then be made for each thread. In some cases, this would add up to a significant amount of wasted memory and would require copying the same data more than necessary. To tackle this issue, one can use an Atomically Reference Counted wrapper (`Arc`) as implemented in the `sync` library of Rust. With an Arc, the data will no longer be copied for each thread. The Arc acts as a reference to the shared data and only this reference is shared and cloned. Here is a small example showing how to use Arcs. We wish to run concurrently several computations on a single large vector of floats. Each thread needs the full vector to perform its duty. ```{rust,ignore} use std::num::Float; use std::rand; use std::sync::Arc; fn pnorm(nums: &[f64], p: u64) -> f64 { nums.iter().fold(0.0, |a, b| a + b.powf(p as f64)).powf(1.0 / (p as f64)) } fn main() { let numbers = Vec::from_fn(1000000, |_| rand::random::<f64>()); let numbers_arc = Arc::new(numbers); for num in range(1, 10) { let thread_numbers = numbers_arc.clone(); spawn(move || { println!("{}-norm = {}", num, pnorm(thread_numbers.as_slice(), num)); }); } } ``` The function `pnorm` performs a simple computation on the vector (it computes the sum of its items at the power given as argument and takes the inverse power of this value). The Arc on the vector is created by the line: ```{rust,ignore} # use std::rand; # use std::sync::Arc; # fn main() { # let numbers = Vec::from_fn(1000000, |_| rand::random::<f64>()); let numbers_arc = Arc::new(numbers); # } ``` and a clone is captured for each thread via a procedure. This only copies the wrapper and not its contents. Within the thread's procedure, the captured Arc reference can be used as a shared reference to the underlying vector as if it were local. ```{rust,ignore} # use std::rand; # use std::sync::Arc; # fn pnorm(nums: &[f64], p: u64) -> f64 { 4.0 } # fn main() { # let numbers=Vec::from_fn(1000000, |_| rand::random::<f64>()); # let numbers_arc = Arc::new(numbers); # let num = 4; let thread_numbers = numbers_arc.clone(); spawn(move || { // Capture thread_numbers and use it as if it was the underlying vector println!("{}-norm = {}", num, pnorm(thread_numbers.as_slice(), num)); }); # } ``` # Handling thread panics Rust has a built-in mechanism for raising exceptions. The `panic!()` macro (which can also be written with an error string as an argument: `panic!( ~reason)`) and the `assert!` construct (which effectively calls `panic!()` if a boolean expression is false) are both ways to raise exceptions. When a thread raises an exception, the thread unwinds its stack—running destructors and freeing memory along the way—and then exits. Unlike exceptions in C++, exceptions in Rust are unrecoverable within a single thread: once a thread panics, there is no way to "catch" the exception. While it isn't possible for a thread to recover from panicking, threads may notify each other if they panic. The simplest way of handling a panic is with the `try` function, which is similar to `spawn`, but immediately blocks and waits for the child thread to finish. `try` returns a value of type `Result<T, Box<Any + Send>>`. `Result` is an `enum` type with two variants: `Ok` and `Err`. In this case, because the type arguments to `Result` are `i32` and `()`, callers can pattern-match on a result to check whether it's an `Ok` result with an `i32` field (representing a successful result) or an `Err` result (representing termination with an error). ```{rust,ignore} # use std::thread::Thread; # fn some_condition() -> bool { false } # fn calculate_result() -> i32 { 0 } let result: Result<i32, Box<std::any::Any + Send>> = Thread::spawn(move || { if some_condition() { calculate_result() } else { panic!("oops!"); } }).join(); assert!(result.is_err()); ``` Unlike `spawn`, the function spawned using `try` may return a value, which `try` will dutifully propagate back to the caller in a [`Result`] enum. If the child thread terminates successfully, `try` will return an `Ok` result; if the child thread panics, `try` will return an `Error` result. [`Result`]: ../std/result/index.html > *Note:* A panicked thread does not currently produce a useful error > value (`try` always returns `Err(())`). In the > future, it may be possible for threads to intercept the value passed to > `panic!()`. But not all panics are created equal. In some cases you might need to abort the entire program (perhaps you're writing an assert which, if it trips, indicates an unrecoverable logic error); in other cases you might want to contain the panic at a certain boundary (perhaps a small piece of input from the outside world, which you happen to be processing in parallel, is malformed such that the processing thread cannot proceed). </del>


Question:
I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!

pub fn set(stack_bounds: (uint, uint), stack_guard: uint, thread: Thread) { THREAD_INFO.with(|c| assert!(c.borrow().is_none())); <del> match thread.name() { Some(name) => unsafe { ::sys::thread::set_name(name); }, None => {} } </del> THREAD_INFO.with(move |c| *c.borrow_mut() = Some(ThreadInfo{ stack_bounds: stack_bounds, stack_guard: stack_guard,


Question:
I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!

use option::Option::{self, Some, None}; use result::Result::{Err, Ok}; use sync::{Mutex, Condvar, Arc}; <ins> use str::Str; </ins> use string::String; use rt::{self, unwind}; use old_io::{Writer, stdio};


Question:
I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!

unsafe { stack::record_os_managed_stack_bounds(my_stack_bottom, my_stack_top); } <ins> match their_thread.name() { Some(name) => unsafe { imp::set_name(name.as_slice()); }, None => {} } </ins> thread_info::set( (my_stack_bottom, my_stack_top), unsafe { imp::guard::current() },


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn foo<U>(t: U) { let y = t(); //~^ ERROR: expected function, found `U` } struct Bar; pub fn some_func() { let f = Bar(); //~^ ERROR: expected function, found `Bar` } fn main() { foo(|| { 1 }); } </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait A { type Output; fn a(&self) -> <Self as A>::X; //~^ ERROR: use of undeclared associated type `A::X` } impl A for u32 { type Output = u32; fn a(&self) -> u32 { 0 } } fn main() { let a: u32 = 0; let b: u32 = a.a(); } </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn identity(a: &u32) -> &u32 { a } fn print_foo(f: &fn(&u32) -> &u32, x: &u32) { print!("{}", (*f)(x)); } fn main() { let x = &4; let f: fn(&u32) -> &u32 = identity; // Didn't print 4 on optimized builds print_foo(&f, x); } </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(core)] extern crate core; use core::marker::Sync; static SARRAY: [i32; 1] = [11]; struct MyStruct { pub arr: *const [i32], } unsafe impl Sync for MyStruct {} static mystruct: MyStruct = MyStruct { arr: &SARRAY }; fn main() {} </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>


Question:
Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>


Question:
Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.

// except according to those terms. /// Creates a `Vec` containing the arguments. <ins> /// /// `vec!` allows `Vec`s to be defined with the same syntax as array expressions. /// There are two forms of this macro: /// /// - Create a `Vec` containing a given list of elements: /// /// ``` /// let v = vec![1, 2, 3]; /// assert_eq!(v[0], 1); /// assert_eq!(v[1], 2); /// assert_eq!(v[2], 3); /// ``` /// /// - Create a `Vec` from a given element and size: /// /// ``` /// let v = vec![1; 3]; /// assert_eq!(v, vec![1, 1, 1]); /// ``` /// /// Note that unlike array expressions this syntax supports all elements /// which implement `Clone` and the number of elements doesn't have to be /// a constant. </ins> #[macro_export] #[stable(feature = "rust1", since = "1.0.0")] macro_rules! vec { <del> ($x:expr; $y:expr) => ( <[_] as $crate::slice::SliceExt>::into_vec( $crate::boxed::Box::new([$x; $y])) </del> <ins> ($elem:expr; $n:expr) => ( $crate::vec::from_elem($elem, $n) </ins> ); ($($x:expr),*) => ( <[_] as $crate::slice::SliceExt>::into_vec(


Question:
Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.

} } <ins> #[doc(hidden)] #[stable(feature = "rust1", since = "1.0.0")] pub fn from_elem<T: Clone>(elem: T, n: usize) -> Vec<T> { unsafe { let mut v = Vec::with_capacity(n); let mut ptr = v.as_mut_ptr(); // Write all elements except the last one for i in 1..n { ptr::write(ptr, Clone::clone(&elem)); ptr = ptr.offset(1); v.set_len(i); // Increment the length in every step in case Clone::clone() panics } if n > 0 { // We can write the last element directly without cloning needlessly ptr::write(ptr, elem); v.set_len(n); } v } } </ins> //////////////////////////////////////////////////////////////////////////////// // Common trait implementations for Vec ////////////////////////////////////////////////////////////////////////////////


Question:
Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.

assert_eq!(vec![1; 2], vec![1, 1]); assert_eq!(vec![1; 1], vec![1]); assert_eq!(vec![1; 0], vec![]); <ins> // from_elem syntax (see RFC 832) let el = Box::new(1); let n = 3; assert_eq!(vec![el; n], vec![Box::new(1), Box::new(1), Box::new(1)]); </ins> }


Question:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.

err.set_primary_message( "cannot initialize a tuple struct which contains private fields", ); <ins> if !def_id.is_local() && self .r .tcx .inherent_impls(def_id) .iter() .flat_map(|impl_def_id| { self.r.tcx.provided_trait_methods(*impl_def_id) }) .any(|assoc| !assoc.fn_has_self_parameter && assoc.name == sym::new) { // FIXME: look for associated functions with Self return type, // instead of relying only on the name and lack of self receiver. err.span_suggestion_verbose( span.shrink_to_hi(), "you might have meant to use the `new` associated function", "::new".to_string(), Applicability::MaybeIncorrect, ); } </ins> // Use spans of the tuple struct definition. self.r.field_def_ids(def_id).map(|field_ids| { field_ids


Question:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.

<ins> // run-rustfix #![allow(dead_code)] struct U <T> { wtf: Option<Box<U<T>>>, x: T, } fn main() { U { wtf: Some(Box::new(U { //~ ERROR cannot initialize a tuple struct which contains private fields wtf: None, x: (), })), x: () }; } </ins>


Question:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.

<ins> // run-rustfix #![allow(dead_code)] struct U <T> { wtf: Option<Box<U<T>>>, x: T, } fn main() { U { wtf: Some(Box(U { //~ ERROR cannot initialize a tuple struct which contains private fields wtf: None, x: (), })), x: () }; } </ins>


Question:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.

<ins> error[E0423]: cannot initialize a tuple struct which contains private fields --> $DIR/suggest-box-new.rs:9:19 | LL |         wtf: Some(Box(U { |                   ^^^ | note: constructor is not visible here due to private fields --> $SRC_DIR/alloc/src/boxed.rs:LL:COL | = note: private field | = note: private field help: you might have meant to use the `new` associated function | LL |         wtf: Some(Box::new(U { |                      +++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>


Question:
is useless () so skip it.
Neither of the macro chapters have sections for "common macros". Should we add one? Presumably there would be quite a few of them.
There is for the macros in std, plus some of the built-in syntax extensions. It's not that easy to find; there used to be a module in the rustdoc output but no longer :( I'm not sure exactly what should be documented where. The built-in syntax extensions like might deserve special mention, as they give you capabilities within that you otherwise would not have. cc
I think , , and also deserve mentions.
I would like to take on the task of documenting all the common macros. I've started them and appreciate some input on how big the final list should be, and if every macro needs an example (or three). What about the most common one, prinln! ? Should that be in there too?
It's not clear to me what doing this issue actually means. Moving some docs between some places?
The original issue was to add several common macro definitions with examples in TRPL, which I agreed with. I'm not sure what's up with the edits.

Exercise: use macros to reduce duplication in the above definition of the `bct!` macro. <ins> # Common macros Here are some common macros you’ll see in Rust code. ## panic! This macro causes the current thread to panic. You can give it a message to panic with: ```rust,no_run panic!("oh no!"); ``` ## vec! The `vec!` macro is used throughout the book, so you’ve probably seen it already. It creates `Vec<T>`s with ease: ```rust let v = vec![1, 2, 3, 4, 5]; ``` It also lets you make vectors with repeating values. For example, a hundred zeroes: ```rust let v = vec![0; 100]; ``` ## assert! and assert_eq! These two macros are used in tests. `assert!` takes a boolean, and `assert_eq!` takes two values and compares them. Truth passes, success `panic!`s. Like this: ```rust,no_run // A-ok! assert!(true); assert_eq!(5, 3 + 2); // nope :( assert!(5 < 3); assert_eq!(5, 3); ``` ## try! `try!` is used for error handling. It takes something that can return a `Result<T, E>`, and gives `T` if it’s a `Ok<T>`, and `return`s with the `Err(E)` if it’s that. Like this: ```rust,no_run use std::fs::File; fn foo() -> std::io::Result<()> { let f = try!(File::create("foo.txt")); Ok(()) } ``` This is cleaner than doing this: ```rust,no_run use std::fs::File; fn foo() -> std::io::Result<()> { let f = File::create("foo.txt"); let f = match f { Ok(t) => t, Err(e) => return Err(e), }; Ok(()) } ``` ## unreachable! This macro is used when you think some code should never execute: ```rust if false { unreachable!(); } ``` Sometimes, the compiler may make you have a different branch that you know will never, ever run. In these cases, use this macro, so that if you end up wrong, you’ll get a `panic!` about it. ```rust let x: Option<i32> = None; match x { Some(_) => unreachable!(), None => println!("I know x is None!"), } ``` ## unimplemented! The `unimplemented!` macro can be used when you’re trying to get your functions to typecheck, and don’t want to worry about writing out the body of the function. One example of this situation is implementing a trait with multiple required methods, where you want to tackle one at a time. Define the others as `unimplemented!` until you’re ready to write them. </ins> # Procedural macros If Rust's macro system can't do what you need, you may want to write a


Question:
On rustc 1.0.0-nightly ( 2015-02-21) (built 2015-02-21) the follow causes an ICE: Full backtrace: error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'assertion failed: != ast::LOCALCRATE', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc- stack backtrace: 1: 0x10b7aebe3 - sys::backtrace::write::hc8e3cee73e646c590nC 2: 0x10b7dcbe5 - panicking::onpanic::h00b47941f5bc8a02HOL 3: 0x10b706418 - rt::unwind::beginunwindinner::h539538ef7f909326UvL 4: 0x108472895 - rt::unwind::beginunwind::h7610573592537740396 5: 0x1087eb7dc - middle::ty::lookuptraitdef::h00103e323589b59cNla 6: 0x108812687 - middle::ty::predicatesfortraitref::h59dd4f8104908ae1Vna 7: 0x10880c125 - middle::traits::util::Elaborator<'cx, 'tcx.Iterator::next::h9dd8ee47ae7ea8d3QkV 8: 0x108811fd1 - middle::traits::util::Supertraits<'cx, 'tcx.Iterator::next::h2583ba3461accfb9rnV 9: 0x108109246 - astconv::asttytoty::closure. 10: 0x1080a36cb - astconv::asttytoty::hb64a583bfbbc7b64Ncw 11: 0x1080ff44d - astconv::asttyargtoty::h51a53c78e1218ba4sbw 12: 0x1080feff0 - vec::Vec<T.FromIterator<T::fromiter::h8575313848639105278 13: 0x1080fc2e0 - astconv::convertanglebracketedparameters::h9209f0db8109fac9biv 14: 0x108101457 - astconv::astpathtotraitref::h2a3b7b2e77e3fde5Vvv 15: 0x1080af1fb - astconv::instantiatetraitref::h65c5bb030d486323Csv 16: 0x1081007ea - astconv::instantiatepolytraitref::hb7df5c75231f22c61qv 17: 0x10813049f - collect::computebounds::h0eb0cb5207e10f2ccTy 18: 0x10811270f - collect::traitdefofitem::hb48744a94bcef339Q2x 19: 0x108110c0f - collect::CollectTraitDefVisitor<'a, '<'v::visititem::h4c7bef27b106e20cS8w 20: 0x10815d07f - checkcrate::closure. 21: 0x10815b02e - checkcrate::hbe2eb4aab434ad7cVjC 22: 0x107ac68db - driver::phase3runanalysispasses::h50728865d3ffa6b2gHa 23: 0x107aabb9d - driver::compileinput::h349b039ebe75c13eGba 24: 0x107b84857 - runcompiler::h1e4d87c6044fbf6dZbc 25: 0x107b81cd1 - thunk::F.Invoke<A, R::invoke::h2059937391804860278 26: 0x107b80930 - rt::unwind::try::tryfn::h11862807381821880905 27: 0x10b8567e9 - rusttryinner 28: 0x10b8567d6 - rusttry 29: 0x107b81095 - thunk::F.Invoke<A, R::invoke::h6573516661401600357 30: 0x10b7c5ac3 - sys::thread::threadstart::h9e3555425c6999b2e4G 31: 0x7fff8fd0d268 - pthreadbody 32: 0x7fff8fd0d1e5 - pthreadbody
This is basically . And on top of , correctly declares there's an illegal recursive type:
Tests in .
Can this be closed?

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Expr : PartialEq<Self::Item> { //~^ ERROR: unsupported cyclic reference between types/traits detected type Item = Expr; } fn main() {} </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that `quote`-related macro are gated by `quote` feature gate. // (To sanity-check the code, uncomment this.) // #![feature(quote)] // FIXME the error message that is current emitted seems pretty bad. #![feature(rustc_private)] #![allow(dead_code, unused_imports, unused_variables)] #[macro_use] extern crate syntax; use syntax::ast; use syntax::codemap::Span; use syntax::parse; struct ParseSess; impl ParseSess { fn cfg(&self) -> ast::CrateConfig { loop { } } fn parse_sess<'a>(&'a self) -> &'a parse::ParseSess { loop { } } fn call_site(&self) -> Span { loop { } } fn ident_of(&self, st: &str) -> ast::Ident { loop { } } fn name_of(&self, st: &str) -> ast::Name { loop { } } } pub fn main() { let ecx = &ParseSess; let x = quote_tokens!(ecx, 3);   //~ ERROR macro undefined: 'quote_tokens!' let x = quote_expr!(ecx, 3);     //~ ERROR macro undefined: 'quote_expr!' let x = quote_ty!(ecx, 3);       //~ ERROR macro undefined: 'quote_ty!' let x = quote_method!(ecx, 3);   //~ ERROR macro undefined: 'quote_method!' let x = quote_item!(ecx, 3);     //~ ERROR macro undefined: 'quote_item!' let x = quote_pat!(ecx, 3);      //~ ERROR macro undefined: 'quote_pat!' let x = quote_arm!(ecx, 3);      //~ ERROR macro undefined: 'quote_arm!' let x = quote_stmt!(ecx, 3);     //~ ERROR macro undefined: 'quote_stmt!' let x = quote_matcher!(ecx, 3);  //~ ERROR macro undefined: 'quote_matcher!' let x = quote_attr!(ecx, 3);     //~ ERROR macro undefined: 'quote_attr!' } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that `#[link_args]` attribute is gated by `link_args` // feature gate. #[link_args = "aFdEfSeVEEE"] extern {} //~^ ERROR the `link_args` attribute is not portable across platforms //~| HELP add #![feature(link_args)] to the crate attributes to enable fn main() { } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. extern { #[link_name = "llvm.sqrt.f32"] fn sqrt(x: f32) -> f32; //~^ ERROR linking to LLVM intrinsics is experimental //~| HELP add #![feature(link_llvm_intrinsics)] to the crate attributes } fn main(){ } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // Test that `#[plugin_registrar]` attribute is gated by `plugin_registrar` // feature gate. </ins> // the registration function isn't typechecked yet #[plugin_registrar] <del> pub fn registrar() {} //~ ERROR compiler plugins are experimental </del> <ins> pub fn registrar() {} //~^ ERROR compiler plugins are experimental //~| HELP add #![feature(plugin_registrar)] to the crate attributes to enable </ins> fn main() {}