Question:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::env; use std::io::prelude::*; use std::process::Command; use std::thread; const THREADS: usize = 20; const WRITES: usize = 100; const WRITE_SIZE: usize = 1024 * 32; fn main() { let args = env::args().collect::<Vec<_>>(); if args.len() == 1 { parent(); } else { child(); } } fn parent() { let me = env::current_exe().unwrap(); let mut cmd = Command::new(me); cmd.arg("run-the-test"); let output = cmd.output().unwrap(); assert!(output.status.success()); assert_eq!(output.stderr.len(), 0); assert_eq!(output.stdout.len(), WRITES * THREADS * WRITE_SIZE); for byte in output.stdout.iter() { assert_eq!(*byte, b'a'); } } fn child() { let threads = (0..THREADS).map(|_| { thread::spawn(|| { let buf = [b'a'; WRITE_SIZE]; for _ in 0..WRITES { write_all(&buf); } }) }).collect::<Vec<_>>(); for thread in threads { thread.join().unwrap(); } } #[cfg(unix)] fn write_all(buf: &[u8]) { use std::fs::File; use std::mem; use std::os::unix::prelude::*; let mut file = unsafe { File::from_raw_fd(1) }; let res = file.write_all(buf); mem::forget(file); res.unwrap(); } #[cfg(windows)] fn write_all(buf: &[u8]) { use std::fs::File; use std::mem; use std::os::windows::raw::*; use std::os::windows::prelude::*; const STD_OUTPUT_HANDLE: u32 = (-11i32) as u32; extern "system" { fn GetStdHandle(handle: u32) -> HANDLE; } let mut file = unsafe { let handle = GetStdHandle(STD_OUTPUT_HANDLE); assert!(!handle.is_null()); File::from_raw_handle(handle) }; let res = file.write_all(buf); mem::forget(file); res.unwrap(); } </ins>


Question:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

<ins> // check-pass use std::borrow::Borrow; trait TNode: Sized { type ConcreteElement: TElement<ConcreteNode = Self>; } trait TElement: Sized { type ConcreteNode: TNode<ConcreteElement = Self>; } trait DomTraversal<N: TNode> { type BorrowElement: Borrow<N::ConcreteElement>; } #[allow(dead_code)] fn recalc_style_at<E, D>() where E: TElement, D: DomTraversal<E::ConcreteNode>, { } fn main() {} </ins>


Question:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

<ins> // check-pass pub trait Test { type Item; type Bundle: From<Self::Item>; } fn fails<T>() where T: Test<Item = String>, { } fn main() {} </ins>


Question:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

<ins> // check-pass trait Foo { type FooT: Foo; } impl Foo for () { type FooT = (); } trait Bar<T: Foo> { type BarT: Bar<T::FooT>; } impl Bar<()> for () { type BarT = (); } #[allow(dead_code)] fn test<C: Bar<()>>() { } fn main() { } </ins>


Question:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

<ins> // check-pass #![feature(associated_type_bounds)] #![feature(type_alias_impl_trait)] fn main() {} trait Bar { type Assoc; } trait Thing { type Out; fn func() -> Self::Out; } struct AssocIsCopy; impl Bar for AssocIsCopy { type Assoc = u8; } impl Thing for AssocIsCopy { type Out = impl Bar<Assoc: Copy>; fn func() -> Self::Out { AssocIsCopy } } </ins>


Question:
failure: Needs some retries here as well cc https://travis-
I'm also seeing problems when resolving with what I assume is my ISP's DNS server, but little to no problems resolving with Google's 8.8.8.8 DNS. Maybe we could configure Travis to use that? This could be (and I assume it is) a temporary malfunction.
We also should NOT be hitting the netbsd’s poor ftp server with every single build for 50MB of data.

# Next, download the NetBSD libc and relevant header files mkdir netbsd <del> curl https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/base.tgz |  </del> <ins> # originally from: # https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/base.tgz curl https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-01-16-netbsd-base.tgz |  </ins> tar xzf - -C netbsd ./usr/include ./usr/lib ./lib <del> curl https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/comp.tgz |  </del> <ins> # originally from: # https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/comp.tgz curl https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-01-16-netbsd-comp.tgz |  </ins> tar xzf - -C netbsd ./usr/include ./usr/lib dst=/usr/local/x86_64-unknown-netbsd


Question:
Will find more multithreading problems.
Nominating for maturity milestone 4, "well-covered".
accepted for well-covered milestone
triage bump
visiting for triage, email from 2013-09-02. Nothing to add.
--fair-sched is new in Valgrind 3.8.0, but Rust now requires Valgrind 3.8.0 for jemalloc anyway (). It also needs platform support, but while --fair-sched=yes will terminate with an error when there is no platform support, --fair-sched=try will fallback. I think we can try this now.
assigning P-low.
Triage: Given sanxiyn's comment, could implement, but not sure where a fix for this goes.

# #   * `CFG_ENABLE_VALGRIND=1` - Run tests under valgrind #   * `VALGRIND_COMPILE=1` - Run the compiler itself under valgrind <del> #                            (may require `CFG_ENABLE_VALGRIND`) </del> <ins> #                            (requires `CFG_ENABLE_VALGRIND`) </ins> # #   * `NO_REBUILD=1` - Don't rebootstrap when testing std #                      (and possibly other crates)


Question:
Will find more multithreading problems.
Nominating for maturity milestone 4, "well-covered".
accepted for well-covered milestone
triage bump
visiting for triage, email from 2013-09-02. Nothing to add.
--fair-sched is new in Valgrind 3.8.0, but Rust now requires Valgrind 3.8.0 for jemalloc anyway (). It also needs platform support, but while --fair-sched=yes will terminate with an error when there is no platform support, --fair-sched=try will fallback. I think we can try this now.
assigning P-low.
Triage: Given sanxiyn's comment, could implement, but not sure where a fix for this goes.

# see https://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/ ifdef CFG_VALGRIND CFG_VALGRIND += --error-exitcode=100  <del> --soname-synonyms=somalloc=NONE  </del> <ins> --fair-sched=try  </ins> --quiet  <ins> --soname-synonyms=somalloc=NONE  </ins> --suppressions=$(CFG_SRC_DIR)src/etc/x86.supp  $(OS_SUPP) ifdef CFG_ENABLE_HELGRIND


Question:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

#![feature(box_into_raw_non_null)] #![feature(box_patterns)] #![feature(box_syntax)] <ins> #![feature(cfg_sanitize)] </ins> #![feature(cfg_target_has_atomic)] #![feature(coerce_unsized)] #![feature(const_generic_impls_guard)]


Question:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

/// necessarily) at _exactly_ `MAX_REFCOUNT + 1` references. const MAX_REFCOUNT: usize = (isize::MAX) as usize; <ins> #[cfg(not(sanitize = "thread"))] macro_rules! acquire { ($x:expr) => { atomic::fence(Acquire) }; } // ThreadSanitizer does not support memory fences. To avoid false positive // reports in Arc / Weak implementation use atomic loads for synchronization // instead. #[cfg(sanitize = "thread")] macro_rules! acquire { ($x:expr) => { $x.load(Acquire) }; } </ins> /// A thread-safe reference-counting pointer. 'Arc' stands for 'Atomically /// Reference Counted'. ///


Question:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

return Err(this); } <del> atomic::fence(Acquire); </del> <ins> acquire!(this.inner().strong); </ins> unsafe { let elem = ptr::read(&this.ptr.as_ref().data);


Question:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

ptr::drop_in_place(&mut self.ptr.as_mut().data); if self.inner().weak.fetch_sub(1, Release) == 1 { <del> atomic::fence(Acquire); </del> <ins> acquire!(self.inner().weak); </ins> Global.dealloc(self.ptr.cast(), Layout::for_value(self.ptr.as_ref())) } }


Question:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

// // [1]: (www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html) // [2]: (https://github.com/rust-lang/rust/pull/41714) <del> atomic::fence(Acquire); </del> <ins> acquire!(self.inner().strong); </ins> unsafe { self.drop_slow();


Question:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

let inner = if let Some(inner) = self.inner() { inner } else { return }; if inner.weak.fetch_sub(1, Release) == 1 { <del> atomic::fence(Acquire); </del> <ins> acquire!(inner.weak); </ins> unsafe { Global.dealloc(self.ptr.cast(), Layout::for_value(self.ptr.as_ref())) } } }


Question:
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)

use common::{Codegen, DebugInfoLldb, DebugInfoGdb, Rustdoc, CodegenUnits}; use common::{Incremental, RunMake, Ui, MirOpt}; use errors::{self, ErrorKind, Error}; <ins> use filetime::FileTime; </ins> use json; use header::TestProps; use header;


Question:
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)

} } <ins> fn check_mir_test_timestamp(&self, test_name: &str, output_file: &Path) { let t = |file| FileTime::from_last_modification_time(&fs::metadata(file).unwrap()); let source_file = &self.testpaths.file; let output_time = t(output_file); let source_time = t(source_file); if source_time > output_time { debug!("source file time: {:?} output file time: {:?}", source_time, output_time); panic!("test source file `{}` is newer than potentially stale output file `{}`.", source_file.display(), test_name); } } </ins> fn compare_mir_test_output(&self, test_name: &str, expected_content: &Vec<&str>) { let mut output_file = PathBuf::new(); output_file.push(self.get_mir_dump_dir()); output_file.push(test_name); debug!("comparing the contests of: {:?}", output_file); debug!("with: {:?}", expected_content); <ins> self.check_mir_test_timestamp(test_name, &output_file); </ins> let mut dumped_file = fs::File::open(output_file.clone()).unwrap(); let mut dumped_string = String::new();


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

{ debug!("note_issue_32330: terr={:?}", terr); match *terr { <del> TypeError::RegionsInsufficientlyPolymorphic(_, &Region::ReVar(vid)) | TypeError::RegionsOverlyPolymorphic(_, &Region::ReVar(vid)) => { match self.region_vars.var_origin(vid) { RegionVariableOrigin::EarlyBoundRegion(_, _, Some(Issue32330 { fn_def_id, region_name })) => { diag.note( &format!("lifetime parameter `{0}` declared on fn `{1}`  appears only in the return type,  but here is required to be higher-ranked,  which means that `{0}` must appear in both  argument and return types", region_name, self.tcx.item_path_str(fn_def_id))); diag.note( &format!("this error is the result of a recent bug fix;  for more information, see issue #33685  <https://github.com/rust-lang/rust/issues/33685>")); } _ => { } } </del> <ins> TypeError::RegionsInsufficientlyPolymorphic(_, _, Some(box Issue32330 { fn_def_id, region_name })) | TypeError::RegionsOverlyPolymorphic(_, _, Some(box Issue32330 { fn_def_id, region_name })) => { diag.note( &format!("lifetime parameter `{0}` declared on fn `{1}`  appears only in the return type,  but here is required to be higher-ranked,  which means that `{0}` must appear in both  argument and return types", region_name, self.tcx.item_path_str(fn_def_id))); diag.note( &format!("this error is the result of a recent bug fix;  for more information, see issue #33685  <https://github.com/rust-lang/rust/issues/33685>")); </ins> } <del> _ => { } </del> <ins> _ => {} </ins> } }


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

InferCtxt, LateBoundRegion, HigherRankedType, <ins> RegionVariableOrigin, </ins> SubregionOrigin, SkolemizationMap}; use super::combine::CombineFields;


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

skol_br, tainted_region); <ins> let issue_32330 = if let &ty::ReVar(vid) = tainted_region { match self.region_vars.var_origin(vid) { RegionVariableOrigin::EarlyBoundRegion(_, _, issue_32330) => { issue_32330.map(Box::new) } _ => None } } else { None }; </ins> if overly_polymorphic { debug!("Overly polymorphic!"); return Err(TypeError::RegionsOverlyPolymorphic(skol_br, <del> tainted_region)); </del> <ins> tainted_region, issue_32330)); </ins> } else { debug!("Not as polymorphic!"); return Err(TypeError::RegionsInsufficientlyPolymorphic(skol_br, <del> tainted_region)); </del> <ins> tainted_region, issue_32330)); </ins> } } }


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

RegionsDoesNotOutlive(&'tcx Region, &'tcx Region), RegionsNotSame(&'tcx Region, &'tcx Region), RegionsNoOverlap(&'tcx Region, &'tcx Region), <del> RegionsInsufficientlyPolymorphic(BoundRegion, &'tcx Region), RegionsOverlyPolymorphic(BoundRegion, &'tcx Region), </del> <ins> RegionsInsufficientlyPolymorphic(BoundRegion, &'tcx Region, Option<Box<ty::Issue32330>>), RegionsOverlyPolymorphic(BoundRegion, &'tcx Region, Option<Box<ty::Issue32330>>), </ins> Sorts(ExpectedFound<Ty<'tcx>>), IntMismatch(ExpectedFound<ty::IntVarValue>), FloatMismatch(ExpectedFound<ast::FloatTy>),


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

RegionsNoOverlap(..) => { write!(f, "lifetimes do not intersect") } <del> RegionsInsufficientlyPolymorphic(br, _) => { </del> <ins> RegionsInsufficientlyPolymorphic(br, _, _) => { </ins> write!(f, "expected bound lifetime parameter {},  found concrete lifetime", br) } <del> RegionsOverlyPolymorphic(br, _) => { </del> <ins> RegionsOverlyPolymorphic(br, _, _) => { </ins> write!(f, "expected concrete lifetime,  found bound lifetime parameter {}", br) }


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

self.note_and_explain_region(db, "...does not overlap ", region2, ""); } <del> RegionsInsufficientlyPolymorphic(_, conc_region) => { </del> <ins> RegionsInsufficientlyPolymorphic(_, conc_region, _) => { </ins> self.note_and_explain_region(db, "concrete lifetime that was found is ", conc_region, ""); } <del> RegionsOverlyPolymorphic(_, &ty::ReVar(_)) => { </del> <ins> RegionsOverlyPolymorphic(_, &ty::ReVar(_), _) => { </ins> // don't bother to print out the message below for // inference variables, it's not very illuminating. } <del> RegionsOverlyPolymorphic(_, conc_region) => { </del> <ins> RegionsOverlyPolymorphic(_, conc_region, _) => { </ins> self.note_and_explain_region(db, "expected concrete lifetime is ", conc_region, ""); }


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

RegionsNoOverlap(a, b) => { return tcx.lift(&(a, b)).map(|(a, b)| RegionsNoOverlap(a, b)) } <del> RegionsInsufficientlyPolymorphic(a, b) => { return tcx.lift(&b).map(|b| RegionsInsufficientlyPolymorphic(a, b)) </del> <ins> RegionsInsufficientlyPolymorphic(a, b, ref c) => { let c = c.clone(); return tcx.lift(&b).map(|b| RegionsInsufficientlyPolymorphic(a, b, c)) </ins> } <del> RegionsOverlyPolymorphic(a, b) => { return tcx.lift(&b).map(|b| RegionsOverlyPolymorphic(a, b)) </del> <ins> RegionsOverlyPolymorphic(a, b, ref c) => { let c = c.clone(); return tcx.lift(&b).map(|b| RegionsOverlyPolymorphic(a, b, c)) </ins> } IntMismatch(x) => IntMismatch(x), FloatMismatch(x) => FloatMismatch(x),


Question:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(closure_to_fn_coercion)] fn main() { let bar: fn(&mut u32) = |_| {}; //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter fn foo(x: Box<Fn(&i32)>) {} let bar = Box::new(|x: &i32| {}) as Box<Fn(_)>; foo(bar); //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter } </ins>


Question:
see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik

- [abi_sysv64](abi-sysv64.md) - [abi_unadjusted](abi-unadjusted.md) - [abi_vectorcall](abi-vectorcall.md) <ins> - [abi_x86_interrupt](abi-x86-interrupt.md) </ins> - [advanced_slice_patterns](advanced-slice-patterns.md) - [alloc_jemalloc](alloc-jemalloc.md) - [alloc_system](alloc-system.md)


Question:
see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik

<ins> # `abi_x86_interrupt` The tracking issue for this feature is: [#40180] [#40180]: https://github.com/rust-lang/rust/issues/40180 ------------------------ </ins>


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

/// # Examples /// /// ``` <del> /// #![feature(float_bits_conv)] </del> /// assert_ne!((1f32).to_bits(), 1f32 as u32); // to_bits() is not casting! /// assert_eq!((12.5f32).to_bits(), 0x41480000); /// /// ``` <del> #[unstable(feature = "float_bits_conv", reason = "recently added", issue = "40470")] </del> <ins> #[stable(feature = "float_bits_conv", since = "1.21.0")] </ins> #[inline] pub fn to_bits(self) -> u32 { unsafe { ::mem::transmute(self) }


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

/// # Examples /// /// ``` <del> /// #![feature(float_bits_conv)] </del> /// use std::f32; /// let v = f32::from_bits(0x41480000); /// let difference = (v - 12.5).abs();


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

/// let snan = 0x7F800001; /// assert_ne!(f32::from_bits(snan).to_bits(), snan); /// ``` <del> #[unstable(feature = "float_bits_conv", reason = "recently added", issue = "40470")] </del> <ins> #[stable(feature = "float_bits_conv", since = "1.21.0")] </ins> #[inline] pub fn from_bits(mut v: u32) -> Self { const EXP_MASK: u32   = 0x7F800000;


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

/// # Examples /// /// ``` <del> /// #![feature(float_bits_conv)] </del> /// assert!((1f64).to_bits() != 1f64 as u64); // to_bits() is not casting! /// assert_eq!((12.5f64).to_bits(), 0x4029000000000000); /// /// ``` <del> #[unstable(feature = "float_bits_conv", reason = "recently added", issue = "40470")] </del> <ins> #[stable(feature = "float_bits_conv", since = "1.21.0")] </ins> #[inline] pub fn to_bits(self) -> u64 { unsafe { ::mem::transmute(self) }


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

/// # Examples /// /// ``` <del> /// #![feature(float_bits_conv)] </del> /// use std::f64; /// let v = f64::from_bits(0x4029000000000000); /// let difference = (v - 12.5).abs();


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

/// let snan = 0x7FF0000000000001; /// assert_ne!(f64::from_bits(snan).to_bits(), snan); /// ``` <del> #[unstable(feature = "float_bits_conv", reason = "recently added", issue = "40470")] </del> <ins> #[stable(feature = "float_bits_conv", since = "1.21.0")] </ins> #[inline] pub fn from_bits(mut v: u64) -> Self { const EXP_MASK: u64   = 0x7FF0000000000000;


Question:
Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
reviewed
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc

#![feature(unwind_attributes)] #![feature(vec_push_all)] #![cfg_attr(test, feature(update_panic_count))] <del> #![cfg_attr(test, feature(float_bits_conv))] </del> #![cfg_attr(not(stage0), default_lib_allocator)]


Question:
seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)

} impl<'a, 'tcx> LateLintPass<'a, 'tcx> for UnusedMut { <del> fn check_expr(&mut self, cx: &LateContext, e: &hir::Expr) { if let hir::ExprMatch(_, ref arms, _) = e.node { for a in arms { self.check_unused_mut_pat(cx, &a.pats) } } </del> <ins> fn check_arm(&mut self, cx: &LateContext, a: &hir::Arm) { self.check_unused_mut_pat(cx, &a.pats) </ins> } <del> fn check_stmt(&mut self, cx: &LateContext, s: &hir::Stmt) { if let hir::StmtDecl(ref d, _) = s.node { if let hir::DeclLocal(ref l) = d.node { self.check_unused_mut_pat(cx, slice::ref_slice(&l.pat)); } } </del> <ins> fn check_local(&mut self, cx: &LateContext, l: &hir::Local) { self.check_unused_mut_pat(cx, slice::ref_slice(&l.pat)); </ins> } fn check_fn(&mut self,


Question:
seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)

let mut a = 3; let mut b = vec![2]; } <ins> // make sure the lint attribute can be turned off on let statements #[deny(unused_mut)] fn bar() { #[allow(unused_mut)] let mut a = 3; let mut b = vec![2]; //~ ERROR: variable does not need to be mutable } </ins>


Question:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view! I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!

This flag will set which lints should be set to the [forbid level](lints/levels.html#forbid). <ins> ## `-Z`: set unstable options This flag will allow you to set unstable options of rustc. In order to set multiple options, the -Z flag can be used multiple times. For example: `rustc -Z verbose -Z time`. Specifying options with -Z is only available on nightly. To view all available options run: `rustc -Z help`. </ins> ## `--cap-lints`: set the most restrictive lint level This flag lets you 'cap' lints, for more, [see here](lints/levels.html#capping-lints).


Question:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view! I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!

} let message = "Usage: rustc [OPTIONS] INPUT"; let nightly_help = if nightly_options::is_nightly_build() { <del> "n    -Z help             Print internal options for debugging rustc" </del> <ins> "n    -Z help             Print unstable compiler options" </ins> } else { "" };


Question:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view! I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!

} fn describe_debug_flags() { <del> println!("nAvailable debug options:n"); </del> <ins> println!("nAvailable options:n"); </ins> print_flag_list("-Z", config::DB_OPTIONS); }


Question: Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

impl NonCamelCaseTypes { fn check_case(&self, cx: &LateContext, sort: &str, name: ast::Name, span: Span) { <ins> fn char_has_case(c: char) -> bool { c.is_lowercase() || c.is_uppercase() } </ins> fn is_camel_case(name: ast::Name) -> bool { let name = name.as_str(); if name.is_empty() {


Question: Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

// start with a non-lowercase letter rather than non-uppercase // ones (some scripts don't have a concept of upper/lowercase) <del> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains('_') </del> <ins> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains("__") && !name.chars().collect::<Vec<_>>().windows(2).any(|pair| { // contains a capitalisable character followed by, or preceded by, an underscore char_has_case(pair[0]) && pair[1] == '_' || char_has_case(pair[1]) && pair[0] == '_' }) </ins> } fn to_camel_case(s: &str) -> String { <del> s.split('_') .flat_map(|word| { </del> <ins> s.trim_matches('_') .split('_') .map(|word| { </ins> word.chars().enumerate().map(|(i, c)| if i == 0 { c.to_uppercase().collect::<String>() } else { c.to_lowercase().collect() }) <ins> .collect::<Vec<_>>() .concat() </ins> }) <ins> .filter(|x| !x.is_empty()) </ins> .collect::<Vec<_>>() <del> .concat() </del> <ins> .iter().fold((String::new(), None), |(acc, prev): (String, Option<&String>), next| { // separate two components with an underscore if their boundary cannot // be distinguished using a uppercase/lowercase case distinction let join = if let Some(prev) = prev { let l = prev.chars().last().unwrap(); let f = next.chars().next().unwrap(); !char_has_case(l) && !char_has_case(f) } else { false }; (acc + if join { "_" } else { "" } + next, Some(next)) }).0 </ins> } if !is_camel_case(name) {


Question: Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

type __ = isize; //~ ERROR type `__` should have a camel case name such as `CamelCase` <ins> struct X86_64; struct X86__64; //~ ERROR type `X86__64` should have a camel case name such as `X86_64` struct Abc_123; //~ ERROR type `Abc_123` should have a camel case name such as `Abc123` struct A1_b2_c3; //~ ERROR type `A1_b2_c3` should have a camel case name such as `A1B2C3` </ins> fn main() { }


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

// required. #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> Chan<T> { fn send(&self, x: T) { chan_send(self, x) } fn try_send(&self, x: T) -> bool { chan_try_send(self, x) }


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

// Use an inherent impl so that imports are not required: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> Port<T> { fn recv(&self) -> T { port_recv(self) } fn try_recv(&self) -> Option<T> { port_try_recv(self) }


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

// Use an inherent impl so that imports are not required: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T:Owned> PortSet<T> { fn recv(&self) -> T { port_set_recv(self) } fn try_recv(&self) -> Option<T> { port_set_try_recv(self) }


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> SharedChan<T> { fn send(&self, x: T) { shared_chan_send(self, x) } fn try_send(&self, x: T) -> bool { shared_chan_try_send(self, x) }


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> impl Reader for @Reader { fn read(&self, bytes: &mut [u8], len: uint) -> uint { self.read(bytes, len)


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> impl Writer for @Writer { fn write(&self, v: &[const u8]) { self.write(v) } fn seek(&self, a: int, b: SeekStyle) { self.seek(a, b) }


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> fn mk_tests(cx: &TestCtxt) -> @ast::item { let ext_cx = cx.ext_cx;


Question:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

// Allow these methods to be used without import: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T:Owned,U:Owned> DuplexStream<T, U> { fn send(&self, x: T) { self.chan.send(x)


Question:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

} #[stable(feature = "collection_debug", since = "1.17.0")] <del> impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for Keys<'a, K, V> { </del> <ins> impl<'a, K: 'a + fmt::Debug, V: 'a> fmt::Debug for Keys<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.debug_list().entries(self.inner.clone()).finish() </del> <ins> f.debug_list().entries(self.clone()).finish() </ins> } }


Question:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

} #[stable(feature = "collection_debug", since = "1.17.0")] <del> impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for Values<'a, K, V> { </del> <ins> impl<'a, K: 'a, V: 'a + fmt::Debug> fmt::Debug for Values<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.debug_list().entries(self.inner.clone()).finish() </del> <ins> f.debug_list().entries(self.clone()).finish() </ins> } }


Question:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

} #[stable(feature = "std_debug", since = "1.16.0")] <del> impl<'a, K: Debug, V: Debug> fmt::Debug for Keys<'a, K, V> { </del> <ins> impl<'a, K: Debug, V> fmt::Debug for Keys<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list() .entries(self.clone())


Question:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

} #[stable(feature = "std_debug", since = "1.16.0")] <del> impl<'a, K: Debug, V: Debug> fmt::Debug for Values<'a, K, V> { </del> <ins> impl<'a, K, V: Debug> fmt::Debug for Values<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list() .entries(self.clone())


Question:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

} } <ins> fn trace_macros_note(cx: &mut ExtCtxt, sp: Span, message: String) { let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(message); } </ins> /// Given `lhses` and `rhses`, this is the new macro we create fn generic_extension<'cx>(cx: &'cx mut ExtCtxt, sp: Span,


Question:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

rhses: &[quoted::TokenTree]) -> Box<MacResult+'cx> { if cx.trace_macros() { <del> let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(format!("expands to `{}! {{ {} }}`", name, arg)); </del> <ins> trace_macros_note(cx, sp, format!("expanding `{}! {{ {} }}`", name, arg)); </ins> } // Which arm's failure should we report? (the one furthest along)


Question:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

}; // rhs has holes ( `$id` and `$(...)` that need filled) let tts = transcribe(&cx.parse_sess.span_diagnostic, Some(named_matches), rhs); <ins> if cx.trace_macros() { trace_macros_note(cx, sp, format!("to `{}`", tts)); } </ins> let directory = Directory { path: cx.current_expansion.module.directory.clone(), ownership: cx.current_expansion.directory_ownership,


Question:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

14 |     println!("Hello, World!"); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: expands to `println! { "Hello, World!" }` = note: expands to `print! { concat ! ( "Hello, World!" , "/n" ) }` </del> <ins> = note: expanding `println! { "Hello, World!" }` = note: to `print ! ( concat ! ( "Hello, World!" , "/n" ) )` = note: expanding `print! { concat ! ( "Hello, World!" , "/n" ) }` = note: to `$crate :: io :: _print ( format_args ! ( concat ! ( "Hello, World!" , "/n" ) ) )` </ins>


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

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let value = 1; match SomeStruct(value) { StructConst1(_) => { }, //~^ ERROR expected tuple struct/variant, found constant `StructConst1` _ => { }, } struct SomeStruct(u8); const StructConst1 : SomeStruct = SomeStruct(1); const StructConst2 : SomeStruct = SomeStruct(2); } </ins>


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

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(associated_consts)] trait Foo { const BAR: i32; fn foo(self) -> &'static i32 { //~^ ERROR the trait bound `Self: std::marker::Sized` is not satisfied &<Self>::BAR } } fn main() {} </ins>


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

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! get_opt { ($tgt:expr, $field:ident) => { if $tgt.has_$field() {} } } fn main() { get_opt!(bar, foo); //~^ ERROR expected `{`, found `foo` } </ins>