Question:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

/// [`Metadata`]: struct.Metadata.html /// [`fs::metadata`]: fn.metadata.html /// [`fs::symlink_metadata`]: fn.symlink_metadata.html <ins> /// [`is_dir`]: struct.FileType.html#method.is_dir /// [`is_file`]: struct.FileType.html#method.is_file </ins> /// [`is_symlink`]: struct.FileType.html#method.is_symlink /// /// # Examples


Question:
This ICEs with 'tyregion() invoked on in appropriate ty: tybot' from Full output from : Sorry for making the poor compiler throw up with my bad code. :(
"Sorry for putting in effort to make your compiler better with no personal gain", you mean! :-D
Can't reproduce this anymore.

#[lang="return_to_mut"] #[inline(always)] pub unsafe fn return_to_mut(a: *u8) { <del> let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; </del> <ins> // Sometimes the box is null, if it is conditionally frozen. // See e.g. #4904. if !a.is_null() { let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; } </ins> } #[lang="check_not_borrowed"]


Question:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

/// # Examples /// /// ``` <del> /// #![feature(path_ancestors)] /// </del> /// use std::path::Path; /// /// let path = Path::new("/foo/bar");


Question:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

/// [`ancestors`]: struct.Path.html#method.ancestors /// [`Path`]: struct.Path.html #[derive(Copy, Clone, Debug)] <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> pub struct Ancestors<'a> { next: Option<&'a Path>, } <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> impl<'a> Iterator for Ancestors<'a> { type Item = &'a Path;


Question:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

} } <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> impl<'a> FusedIterator for Ancestors<'a> {} ////////////////////////////////////////////////////////////////////////////////


Question:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

/// # Examples /// /// ``` <del> /// #![feature(path_ancestors)] /// </del> /// use std::path::Path; /// /// let mut ancestors = Path::new("/foo/bar").ancestors();


Question:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

/// /// [`None`]: ../../std/option/enum.Option.html#variant.None /// [`parent`]: struct.Path.html#method.parent <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> pub fn ancestors(&self) -> Ancestors { Ancestors { next: Some(&self),


Question:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

use ich::{self, CachingCodemapView, Fingerprint}; use middle::cstore::CrateStore; use ty::{TyCtxt, fast_reject}; <ins> use mir::interpret::AllocId; </ins> use session::Session; use std::cmp::Ord;


Question:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

// CachingCodemapView, so we initialize it lazily. raw_codemap: &'a CodeMap, caching_codemap: Option<CachingCodemapView<'a>>, <ins> pub(super) alloc_id_recursion_tracker: FxHashSet<AllocId>, </ins> } #[derive(PartialEq, Eq, Clone, Copy)]


Question:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

hash_spans: hash_spans_initial, hash_bodies: true, node_id_hashing_mode: NodeIdHashingMode::HashDefPath, <ins> alloc_id_recursion_tracker: Default::default(), </ins> } }


Question:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

}); enum AllocDiscriminant { <del> Static, Constant, </del> <ins> Alloc, ExternStatic, </ins> Function, } impl_stable_hash_for!(enum self::AllocDiscriminant { <del> Static, Constant, </del> <ins> Alloc, ExternStatic, </ins> Function });


Question:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

) { ty::tls::with_opt(|tcx| { let tcx = tcx.expect("can't hash AllocIds during hir lowering"); <del> if let Some(def_id) = tcx.interpret_interner.get_corresponding_static_def_id(*self) { AllocDiscriminant::Static.hash_stable(hcx, hasher); // statics are unique via their DefId def_id.hash_stable(hcx, hasher); } else if let Some(alloc) = tcx.interpret_interner.get_alloc(*self) { // not a static, can't be recursive, hash the allocation AllocDiscriminant::Constant.hash_stable(hcx, hasher); alloc.hash_stable(hcx, hasher); </del> <ins> if let Some(alloc) = tcx.interpret_interner.get_alloc(*self) { AllocDiscriminant::Alloc.hash_stable(hcx, hasher); if !hcx.alloc_id_recursion_tracker.insert(*self) { tcx .interpret_interner .get_corresponding_static_def_id(*self) .hash_stable(hcx, hasher); alloc.hash_stable(hcx, hasher); assert!(hcx.alloc_id_recursion_tracker.remove(self)); } </ins> } else if let Some(inst) = tcx.interpret_interner.get_fn(*self) { AllocDiscriminant::Function.hash_stable(hcx, hasher); inst.hash_stable(hcx, hasher); <ins> } else if let Some(def_id) = tcx.interpret_interner .get_corresponding_static_def_id(*self) { AllocDiscriminant::ExternStatic.hash_stable(hcx, hasher); def_id.hash_stable(hcx, hasher); </ins> } else { bug!("no allocation for {}", self); }


Question:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // https://github.com/rust-lang/rust/issues/49081 // revisions:rpass1 rpass2 #[cfg(rpass1)] pub static A: &str = "hello"; #[cfg(rpass2)] pub static A: &str = "xxxxx"; #[cfg(rpass1)] fn main() { assert_eq!(A, "hello"); } #[cfg(rpass2)] fn main() { assert_eq!(A, "xxxxx"); } </ins>


Question:
Documentation on states: However, this code panics on both store and load (if the call to store() is commented out) Either documentation should be updated to describe why this is not relevant to store/load, or implementation should be fixed to actually deliver on the promise.
The implementation is correct. AcquireRelease is an ordering for operations that both load and store. If you just have a load or a store, you can and should simply use acquire or release respectively.
Ok, makes sense. Then the documentation should reflect that more clearly.

/// [`Release`]: http://llvm.org/docs/Atomics.html#release #[stable(feature = "rust1", since = "1.0.0")] Acquire, <del> /// When coupled with a load, uses [`Acquire`] ordering, and with a store /// [`Release`] ordering. </del> <ins> /// Has the effects of both [`Acquire`] and [`Release`] together. /// /// This ordering is only applicable for operations that combine both loads and stores. /// /// For loads it uses [`Acquire`] ordering. For stores it uses the [`Release`] ordering. </ins> /// /// [`Acquire`]: http://llvm.org/docs/Atomics.html#acquire /// [`Release`]: http://llvm.org/docs/Atomics.html#release


Question:
Nobody responded to , and the rabbit hole has only gotten deeper and deeper since I've started trying to work around this . It's time for an issue. Here's a simple pattern macro: Trouble is, suppose somebody writes . Then they'll get this: Here is the simplest alternative I can come up with for working around this warning in this simple macro. Notice how proper support for and requires that the macro output uses shorthand field syntax, as opposed to a more scalable workaround like (where the is at least something that could be produced by a helper macro). A similar pattern macro for a struct with two fields basically requires an incremental muncher now, just to avoid the exponential blowup of rules. This is an awful lot of headache just for a little reminder to write more idiomatic code! Isn't that clippy's job, anyhow?
A crude fix would be to just not trigger this lint in macro expansions (at the cost of missing out on linting macro code where the offending non-shorthand pattern doesn't come as an argument, which, ideally, should be linted):

} if let PatKind::Binding(_, _, name, None) = fieldpat.node.pat.node { if name.node == fieldpat.node.name { <ins> if let Some(_) = fieldpat.span.ctxt().outer().expn_info() { // Don't lint if this is a macro expansion: macro authors // shouldn't have to worry about this kind of style issue // (Issue #49588) return; } </ins> let mut err = cx.struct_span_lint(NON_SHORTHAND_FIELD_PATTERNS, fieldpat.span, &format!("the `{}:` in this pattern is redundant",


Question:
Nobody responded to , and the rabbit hole has only gotten deeper and deeper since I've started trying to work around this . It's time for an issue. Here's a simple pattern macro: Trouble is, suppose somebody writes . Then they'll get this: Here is the simplest alternative I can come up with for working around this warning in this simple macro. Notice how proper support for and requires that the macro output uses shorthand field syntax, as opposed to a more scalable workaround like (where the is at least something that could be produced by a helper macro). A similar pattern macro for a struct with two fields basically requires an incremental muncher now, just to avoid the exponential blowup of rules. This is an awful lot of headache just for a little reminder to write more idiomatic code! Isn't that clippy's job, anyhow?
A crude fix would be to just not trigger this lint in macro expansions (at the cost of missing out on linting macro code where the offending non-shorthand pattern doesn't come as an argument, which, ideally, should be linted):

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![deny(non_shorthand_field_patterns)] pub struct Value<A> { pub value: A } #[macro_export] macro_rules! pat { ($a:pat) => { Value { value: $a } }; } fn main() { let pat!(value) = Value { value: () }; } </ins>


Question:
I have a Rust written using the msp430 backend. which means using the nightly compiler. Travis CI daily cron builds have been with the nightly compiler since March 27, 2018 with the following error (I am currently not in a position to get a backtrace/increase verbosity, I will update when possible): My msp430 firmware uses to create a for msp430 every time is updated, and recently a new feature has triggered a lint that causes compilation to fail due to an unused macro. Since can't be compiled, the whole build fails. A stopgap solution for now is to use a nightly before March 27, 2018 which compiles for msp430 successfully. cc: based on a in with PR might have tickled the lint into failing compilation for the msp430 backend?
This macro is conditionally used in code that depends on the target’s pointer width. I suspect that this error happens on any 16-bit platform. Adding to the macro’s definition should fix it. Would you send a PR and ping me for review? (As an aside, we should probably have CI on rust-lang/rust that libcore at least compiles for one 16-bit platform.)
Looking at 's fix I guess my q is: why don't 16 bit targets (msp430/avr) need this macro at all?
has some background on the removal of conversions for some combinations of integer types. Here we have a private trait with a generic impl based on and some concrete impls to "restore" missing conversions. The implementation of those concrete conversion depends on the size of : we either check that the source value isn’t too large for the target type, or check nothing at all because the target type covers all values of the source type. When is 16-bits, the minimum, only the latter kind of conversion is used.

} // unsigned to signed (only positive bound) <ins> #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))] </ins> macro_rules! try_from_upper_bounded { ($($target:ty),*) => {$( impl PrivateTryFromUsize for $target {


Question:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

// all span information. // // As a result, some AST nodes are annotated with the token <del> // stream they came from. Attempt to extract these lossless // token streams before we fall back to the stringification. </del> <ins> // stream they came from. Here we attempt to extract these // lossless token streams before we fall back to the // stringification. // // During early phases of the compiler, though, the AST could // get modified directly (e.g. attributes added or removed) and // the internal cache of tokens my not be invalidated or // updated. Consequently if the "lossless" token stream // disagrees with our actuall stringification (which has // historically been much more battle-tested) then we go with // the lossy stream anyway (losing span information). </ins> let mut tokens = None; match nt.0 {


Question:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

_ => {} } <del> tokens.unwrap_or_else(|| { nt.1.force(|| { // FIXME(jseyfried): Avoid this pretty-print + reparse hack let source = pprust::token_to_string(self); parse_stream_from_source_str(FileName::MacroExpansion, source, sess, Some(span)) }) }) </del> <ins> let tokens_for_real = nt.1.force(|| { // FIXME(#43081): Avoid this pretty-print + reparse hack let source = pprust::token_to_string(self); parse_stream_from_source_str(FileName::MacroExpansion, source, sess, Some(span)) }); if let Some(tokens) = tokens { if tokens.eq_unspanned(&tokens_for_real) { return tokens } } return tokens_for_real </ins> } }


Question:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

(&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => tk == tk2, (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && <del> dl.stream().trees().zip(dl2.stream().trees()).all(|(tt, tt2)| tt.eq_unspanned(&tt2)) </del> <ins> dl.stream().eq_unspanned(&dl2.stream()) </ins> } (_, _) => false, }


Question:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

/// Compares two TokenStreams, checking equality without regarding span information. pub fn eq_unspanned(&self, other: &TokenStream) -> bool { <del> for (t1, t2) in self.trees().zip(other.trees()) { </del> <ins> let mut t1 = self.trees(); let mut t2 = other.trees(); for (t1, t2) in t1.by_ref().zip(t2.by_ref()) { </ins> if !t1.eq_unspanned(&t2) { return false; } } <del> true </del> <ins> t1.next().is_none() && t2.next().is_none() </ins> } /// Precondition: `self` consists of a single token tree.


Question:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro)] extern crate proc_macro; use proc_macro::*; #[proc_macro_attribute] pub fn assert1(_a: TokenStream, b: TokenStream) -> TokenStream { assert_eq(b.clone(), "pub fn foo() {}".parse().unwrap()); b } #[proc_macro_derive(Foo, attributes(foo))] pub fn assert2(a: TokenStream) -> TokenStream { assert_eq(a, "pub struct MyStructc { _a: i32, }".parse().unwrap()); TokenStream::empty() } fn assert_eq(a: TokenStream, b: TokenStream) { let mut a = a.into_iter(); let mut b = b.into_iter(); for (a, b) in a.by_ref().zip(&mut b) { match (a, b) { (TokenTree::Group(a), TokenTree::Group(b)) => { assert_eq!(a.delimiter(), b.delimiter()); assert_eq(a.stream(), b.stream()); } (TokenTree::Op(a), TokenTree::Op(b)) => { assert_eq!(a.op(), b.op()); assert_eq!(a.spacing(), b.spacing()); } (TokenTree::Literal(a), TokenTree::Literal(b)) => { assert_eq!(a.to_string(), b.to_string()); } (TokenTree::Term(a), TokenTree::Term(b)) => { assert_eq!(a.to_string(), b.to_string()); } (a, b) => panic!("{:?} != {:?}", a, b), } } assert!(a.next().is_none()); assert!(b.next().is_none()); } </ins>


Question:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:modify-ast.rs #![feature(proc_macro)] extern crate modify_ast; use modify_ast::*; #[derive(Foo)] pub struct MyStructc { #[cfg_attr(my_cfg, foo)] _a: i32, } macro_rules! a { ($i:item) => ($i) } a! { #[assert1] pub fn foo() {} } fn main() { let _a = MyStructc { _a: 0 }; foo(); } </ins>


Question:
Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)

} #[test] <ins> fn test_str_slice_rangetoinclusive_ok() { let s = "abcαβγ"; assert_eq!(&s[..=2], "abc"); assert_eq!(&s[..=4], "abcα"); } #[test] #[should_panic] fn test_str_slice_rangetoinclusive_notok() { let s = "abcαβγ"; &s[..=3]; } #[test] fn test_str_slicemut_rangetoinclusive_ok() { let mut s = "abcαβγ".to_owned(); let s: &mut str = &mut s; assert_eq!(&mut s[..=2], "abc"); assert_eq!(&mut s[..=4], "abcα"); } #[test] #[should_panic] fn test_str_slicemut_rangetoinclusive_notok() { let mut s = "abcαβγ".to_owned(); let s: &mut str = &mut s; &mut s[..=3]; } #[test] </ins> fn test_is_char_boundary() { let s = "ศไทย中华Việt Nam β-release 🐱123"; assert!(s.is_char_boundary(0));


Question:
Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)

fn index(self, slice: &str) -> &Self::Output { assert!(self.end != usize::max_value(), "attempted to index str up to maximum usize"); <del> let end = self.end + 1; self.get(slice).unwrap_or_else(|| super::slice_error_fail(slice, 0, end)) </del> <ins> (..self.end+1).index(slice) </ins> } #[inline] fn index_mut(self, slice: &mut str) -> &mut Self::Output { assert!(self.end != usize::max_value(), "attempted to index str up to maximum usize"); <del> if slice.is_char_boundary(self.end) { unsafe { self.get_unchecked_mut(slice) } } else { super::slice_error_fail(slice, 0, self.end + 1) } </del> <ins> (..self.end+1).index_mut(slice) </ins> } }


Question:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

continue; } <del> let result = select.select(&Obligation::new(dummy_cause.clone(), new_env, pred)); </del> <ins> // Call infcx.resolve_type_vars_if_possible to see if we can // get rid of any inference variables. let obligation = infcx.resolve_type_vars_if_possible( &Obligation::new(dummy_cause.clone(), new_env, pred) ); let result = select.select(&obligation); </ins> match &result { &Ok(Some(ref vtable)) => {


Question:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

} &Ok(None) => {} &Err(SelectionError::Unimplemented) => { <del> if self.is_of_param(pred.skip_binder().trait_ref.substs) { </del> <ins> if self.is_param_no_infer(pred.skip_binder().trait_ref.substs) { </ins> already_visited.remove(&pred); self.add_user_pred( &mut user_computed_preds,


Question:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

finished_map } <del> pub fn is_of_param(&self, substs: &Substs<'_>) -> bool { if substs.is_noop() { return false; } </del> <ins> fn is_param_no_infer(&self, substs: &Substs<'_>) -> bool { return self.is_of_param(substs.type_at(0)) && !substs.types().any(|t| t.has_infer_types()); } </ins> <del> return match substs.type_at(0).sty { </del> <ins> pub fn is_of_param(&self, ty: Ty<'_>) -> bool { return match ty.sty { </ins> ty::Param(_) => true, <del> ty::Projection(p) => self.is_of_param(p.substs), </del> <ins> ty::Projection(p) => self.is_of_param(p.self_ty()), </ins> _ => false, }; } <ins> fn is_self_referential_projection(&self, p: ty::PolyProjectionPredicate<'_>) -> bool { match p.ty().skip_binder().sty { ty::Projection(proj) if proj == p.skip_binder().projection_ty => { true }, _ => false } } </ins> pub fn evaluate_nested_obligations< 'b, 'c,


Question:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

) -> bool { let dummy_cause = ObligationCause::misc(DUMMY_SP, ast::DUMMY_NODE_ID); <del> for (obligation, predicate) in nested .filter(|o| o.recursion_depth == 1) </del> <ins> for (obligation, mut predicate) in nested </ins> .map(|o| (o.clone(), o.predicate.clone())) { let is_new_pred = fresh_preds.insert(self.clean_pred(select.infcx(), predicate.clone())); <ins> // Resolve any inference variables that we can, to help selection succeed predicate = select.infcx().resolve_type_vars_if_possible(&predicate); // We only add a predicate as a user-displayable bound if // it involves a generic parameter, and doesn't contain // any inference variables. // // Displaying a bound involving a concrete type (instead of a generic // parameter) would be pointless, since it's always true // (e.g. u8: Copy) // Displaying an inference variable is impossible, since they're // an internal compiler detail without a defined visual representation // // We check this by calling is_of_param on the relevant types // from the various possible predicates </ins> match &predicate { &ty::Predicate::Trait(ref p) => { <del> let substs = &p.skip_binder().trait_ref.substs; </del> <ins> if self.is_param_no_infer(p.skip_binder().trait_ref.substs) && !only_projections && is_new_pred { </ins> <del> if self.is_of_param(substs) && !only_projections && is_new_pred { </del> self.add_user_pred(computed_preds, predicate); } predicates.push_back(p.clone()); } &ty::Predicate::Projection(p) => { <del> // If the projection isn't all type vars, then // we don't want to add it as a bound if self.is_of_param(p.skip_binder().projection_ty.substs) && is_new_pred { self.add_user_pred(computed_preds, predicate); } else { </del> <ins> debug!("evaluate_nested_obligations: examining projection predicate {:?}", predicate); // As described above, we only want to display // bounds which include a generic parameter but don't include // an inference variable. // Additionally, we check if we've seen this predicate before, // to avoid rendering duplicate bounds to the user. if self.is_param_no_infer(p.skip_binder().projection_ty.substs) && !p.ty().skip_binder().is_ty_infer() && is_new_pred { debug!("evaluate_nested_obligations: adding projection predicate to computed_preds: {:?}", predicate); // Under unusual circumstances, we can end up with a self-refeential // projection predicate. For example: // <T as MyType>::Value == <T as MyType>::Value // Not only is displaying this to the user pointless, // having it in the ParamEnv will cause an issue if we try to call // poly_project_and_unify_type on the predicate, since this kind of // predicate will normally never end up in a ParamEnv. // // For these reasons, we ignore these weird predicates, // ensuring that we're able to properly synthesize an auto trait impl if self.is_self_referential_projection(p) { debug!("evaluate_nested_obligations: encountered a projection predicate equating a type with itself! Skipping"); } else { self.add_user_pred(computed_preds, predicate); } } // We can only call poly_project_and_unify_type when our predicate's // Ty is an inference variable - otherwise, there won't be anything to // unify if p.ty().skip_binder().is_ty_infer() { debug!("Projecting and unifying projection predicate {:?}", predicate); </ins> match poly_project_and_unify_type(select, &obligation.with(p.clone())) { Err(e) => { debug!(


Question:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub trait Signal { type Item; } pub trait Signal2 { type Item2; } impl<B, C> Signal2 for B where B: Signal<Item = C> { type Item2 = C; } // @has issue_50159/struct.Switch.html // @has - '//code' 'impl<B> Send for Switch<B> where <B as Signal>::Item: Send' // @has - '//code' 'impl<B> Sync for Switch<B> where <B as Signal>::Item: Sync' // @count - '//*[@id="implementations-list"]/*[@class="impl"]' 0 // @count - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]' 2 pub struct Switch<B: Signal> { pub inner: <B as Signal2>::Item2, } </ins>


Question:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Some unusual code minimized from // https://github.com/sile/handy_async/tree/7b619b762c06544fc67792c8ff8ebc24a88fdb98 pub trait Pattern { type Value; } pub struct Constrain<A, B = A, C = A>(A, B, C); impl<A, B, C> Pattern for Constrain<A, B, C> where A: Pattern, B: Pattern<Value = A::Value>, C: Pattern<Value = A::Value>, { type Value = A::Value; } pub struct Wrapper<T>(T); impl<T> Pattern for Wrapper<T> { type Value = T; } // @has self_referential/struct.WriteAndThen.html // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<P1> Send for  // WriteAndThen<P1>  where  <P1 as Pattern>::Value: Send" pub struct WriteAndThen<P1>(pub P1::Value,pub <Constrain<P1, Wrapper<P1::Value>> as Pattern>::Value) where P1: Pattern; </ins>


Question:
I came across . This is a "safe" feature of rust I didn't know about. I was at first confused about the docs for however. My main confusion was around the "deinitializing" word which made me think that is not consumed. It is consumed but it is not dropped, which is a subtle distinction. I propose here to remove the confusing language. Suggested new docs: Another possible option (I don't like it as much but it is more similar to the previous docs): As a side note, I have not seen the "deinitialized" qualifier in rust before. I don't think it is part of the standard rust lingo which is probably some of my confusion :smile:
Another option, which I think is the best of both worlds: The important points are to mention that is moved, and to use standard terminology rather than "deinitialized".
I like the third option the most:
I have to say I like yours the best. Maybe change "Moves behind the mutable reference" to "Moves into the mutable reference"? I'm not sure "behind" is standard lingo either :smile:
opened a pr

} } <del> /// Replaces the value at a mutable location with a new one, returning the old value, without /// deinitializing either one. </del> <ins> /// Moves `src` into the referenced `dest`, returning the previous `dest` value. /// /// Neither value is dropped. </ins> /// /// # Examples ///


Question:
I came across . This is a "safe" feature of rust I didn't know about. I was at first confused about the docs for however. My main confusion was around the "deinitializing" word which made me think that is not consumed. It is consumed but it is not dropped, which is a subtle distinction. I propose here to remove the confusing language. Suggested new docs: Another possible option (I don't like it as much but it is more similar to the previous docs): As a side note, I have not seen the "deinitialized" qualifier in rust before. I don't think it is part of the standard rust lingo which is probably some of my confusion :smile:
Another option, which I think is the best of both worlds: The important points are to mention that is moved, and to use standard terminology rather than "deinitialized".
I like the third option the most:
I have to say I like yours the best. Maybe change "Moves behind the mutable reference" to "Moves into the mutable reference"? I'm not sure "behind" is standard lingo either :smile:
opened a pr

} } <del> /// Replaces the value at `dest` with `src`, returning the old /// value, without dropping either. </del> <ins> /// Moves `src` into the pointed `dest`, returning the previous `dest` value. /// /// Neither value is dropped. </ins> /// /// # Safety ///


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

use crate::resolve_imports::{ImportDirective, ImportDirectiveSubclass, ImportResolver}; use crate::{path_names_to_string, KNOWN_TOOLS}; <del> use crate::{CrateLint, LegacyScope, Module, ModuleOrUniformRoot}; </del> <ins> use crate::{BindingError, CrateLint, LegacyScope, Module, ModuleOrUniformRoot}; </ins> use crate::{PathResult, ParentScope, ResolutionError, Resolver, Scope, ScopeSet, Segment}; type Res = def::Res<ast::NodeId>;


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

err } ResolutionError::VariableNotBoundInPattern(binding_error) => { <del> let target_sp = binding_error.target.iter().cloned().collect::<Vec<_>>(); </del> <ins> let BindingError { name, target, origin, could_be_path } = binding_error; let target_sp = target.iter().copied().collect::<Vec<_>>(); let origin_sp = origin.iter().copied().collect::<Vec<_>>(); </ins> let msp = MultiSpan::from_spans(target_sp.clone()); <del> let msg = format!("variable `{}` is not bound in all patterns", binding_error.name); </del> <ins> let msg = format!("variable `{}` is not bound in all patterns", name); </ins> let mut err = self.session.struct_span_err_with_code( msp, &msg, DiagnosticId::Error("E0408".into()), ); for sp in target_sp { <del> err.span_label(sp, format!("pattern doesn't bind `{}`", binding_error.name)); </del> <ins> err.span_label(sp, format!("pattern doesn't bind `{}`", name)); </ins> } <del> let origin_sp = binding_error.origin.iter().cloned(); </del> for sp in origin_sp { err.span_label(sp, "variable not in all patterns"); } <ins> if *could_be_path { let help_msg = format!( "if you meant to match on a variant or a `const` item, consider  making the path in the pattern qualified: `?::{}`", name, ); err.span_help(span, &help_msg); } </ins> err } ResolutionError::VariableBoundWithDifferentMode(variable_name,


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

// Checks that all of the arms in an or-pattern have exactly the // same set of bindings, with the same binding modes for each. fn check_consistent_bindings(&mut self, pats: &[P<Pat>]) { <del> if pats.is_empty() { return; } </del> let mut missing_vars = FxHashMap::default(); let mut inconsistent_vars = FxHashMap::default(); <del> for (i, p) in pats.iter().enumerate() { let map_i = self.binding_mode_map(&p); for (j, q) in pats.iter().enumerate() { if i == j { continue; } let map_j = self.binding_mode_map(&q); for (&key, &binding_i) in &map_i { if map_j.is_empty() {                   // Account for missing bindings when let binding_error = missing_vars    // `map_j` has none. .entry(key.name) .or_insert(BindingError { name: key.name, origin: BTreeSet::new(), target: BTreeSet::new(), }); binding_error.origin.insert(binding_i.span); binding_error.target.insert(q.span); } for (&key_j, &binding_j) in &map_j { match map_i.get(&key_j) { None => {  // missing binding let binding_error = missing_vars .entry(key_j.name) .or_insert(BindingError { name: key_j.name, origin: BTreeSet::new(), target: BTreeSet::new(), }); binding_error.origin.insert(binding_j.span); binding_error.target.insert(p.span); } Some(binding_i) => {  // check consistent binding if binding_i.binding_mode != binding_j.binding_mode { inconsistent_vars .entry(key.name) .or_insert((binding_j.span, binding_i.span)); } </del> <ins> for pat_outer in pats.iter() { let map_outer = self.binding_mode_map(&pat_outer); for pat_inner in pats.iter().filter(|pat| pat.id != pat_outer.id) { let map_inner = self.binding_mode_map(&pat_inner); for (&key_inner, &binding_inner) in map_inner.iter() { match map_outer.get(&key_inner) { None => {  // missing binding let binding_error = missing_vars .entry(key_inner.name) .or_insert(BindingError { name: key_inner.name, origin: BTreeSet::new(), target: BTreeSet::new(), could_be_path: key_inner.name.as_str().starts_with(char::is_uppercase) }); binding_error.origin.insert(binding_inner.span); binding_error.target.insert(pat_outer.span); } Some(binding_outer) => {  // check consistent binding if binding_outer.binding_mode != binding_inner.binding_mode { inconsistent_vars .entry(key_inner.name) .or_insert((binding_inner.span, binding_outer.span)); </ins> } } } } } } <del> let mut missing_vars = missing_vars.iter().collect::<Vec<_>>(); </del> <ins> let mut missing_vars = missing_vars.iter_mut().collect::<Vec<_>>(); </ins> missing_vars.sort(); <del> for (_, v) in missing_vars { </del> <ins> for (name, mut v) in missing_vars { if inconsistent_vars.contains_key(name) { v.could_be_path = false; } </ins> self.r.report_error( <del> *v.origin.iter().next().unwrap(), ResolutionError::VariableNotBoundInPattern(v) ); </del> <ins> *v.origin.iter().next().unwrap(), ResolutionError::VariableNotBoundInPattern(v)); </ins> } let mut inconsistent_vars = inconsistent_vars.iter().collect::<Vec<_>>(); inconsistent_vars.sort(); for (name, v) in inconsistent_vars {


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

self.resolve_pattern(pat, source, &mut bindings_list); } // This has to happen *after* we determine which pat_idents are variants <del> self.check_consistent_bindings(pats); </del> <ins> if pats.len() > 1 { self.check_consistent_bindings(pats); } </ins> } fn resolve_block(&mut self, block: &Block) {


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

name: Name, origin: BTreeSet<Span>, target: BTreeSet<Span>, <ins> could_be_path: bool </ins> } impl PartialOrd for BindingError {


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

<ins> #![allow(non_camel_case_types)] enum E { A, B, c } mod m { const CONST1: usize = 10; const Const2: usize = 20; } </ins> fn main() { let y = 1; match y { a | b => {} //~  ERROR variable `a` is not bound in all patterns <del> //~^ ERROR variable `b` is not bound in all patterns </del> <ins> //~| ERROR variable `b` is not bound in all patterns } let x = (E::A, E::B); match x { (A, B) | (ref B, c) | (c, A) => () //~^ ERROR variable `A` is not bound in all patterns //~| ERROR variable `B` is not bound in all patterns //~| ERROR variable `B` is bound in inconsistent ways //~| ERROR mismatched types //~| ERROR variable `c` is not bound in all patterns //~| HELP consider making the path in the pattern qualified: `?::A` } let z = (10, 20); match z { (CONST1, _) | (_, Const2) => () //~^ ERROR variable `CONST1` is not bound in all patterns //~| HELP consider making the path in the pattern qualified: `?::CONST1` //~| ERROR variable `Const2` is not bound in all patterns //~| HELP consider making the path in the pattern qualified: `?::Const2` </ins> } }


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

error[E0408]: variable `a` is not bound in all patterns <del> --> $DIR/resolve-inconsistent-names.rs:4:12 </del> <ins> --> $DIR/resolve-inconsistent-names.rs:13:12 </ins> | LL |        a | b => {} |        -   ^ pattern doesn't bind `a`


Question:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

|        variable not in all patterns error[E0408]: variable `b` is not bound in all patterns <del> --> $DIR/resolve-inconsistent-names.rs:4:8 </del> <ins> --> $DIR/resolve-inconsistent-names.rs:13:8 </ins> | LL |        a | b => {} |        ^   - variable not in all patterns |        | |        pattern doesn't bind `b` <del> error: aborting due to 2 previous errors </del> <ins> error[E0408]: variable `A` is not bound in all patterns --> $DIR/resolve-inconsistent-names.rs:19:18 | LL |         (A, B) | (ref B, c) | (c, A) => () |          -       ^^^^^^^^^^       - variable not in all patterns |          |       | |          |       pattern doesn't bind `A` |          variable not in all patterns | help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `?::A` --> $DIR/resolve-inconsistent-names.rs:19:10 | LL |         (A, B) | (ref B, c) | (c, A) => () |          ^ error[E0408]: variable `B` is not bound in all patterns --> $DIR/resolve-inconsistent-names.rs:19:31 | LL |         (A, B) | (ref B, c) | (c, A) => () |             -         -       ^^^^^^ pattern doesn't bind `B` |             |         | |             |         variable not in all patterns |             variable not in all patterns error[E0408]: variable `c` is not bound in all patterns --> $DIR/resolve-inconsistent-names.rs:19:9 | LL |         (A, B) | (ref B, c) | (c, A) => () |         ^^^^^^           -     - variable not in all patterns |         |                | |         |                variable not in all patterns |         pattern doesn't bind `c` error[E0409]: variable `B` is bound in inconsistent ways within the same match arm --> $DIR/resolve-inconsistent-names.rs:19:23 | LL |         (A, B) | (ref B, c) | (c, A) => () |             -         ^ bound in different ways |             | |             first binding error[E0408]: variable `CONST1` is not bound in all patterns --> $DIR/resolve-inconsistent-names.rs:30:23 | LL |         (CONST1, _) | (_, Const2) => () |          ------       ^^^^^^^^^^^ pattern doesn't bind `CONST1` |          | |          variable not in all patterns | help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `?::CONST1` --> $DIR/resolve-inconsistent-names.rs:30:10 | LL |         (CONST1, _) | (_, Const2) => () |          ^^^^^^ error[E0408]: variable `Const2` is not bound in all patterns --> $DIR/resolve-inconsistent-names.rs:30:9 | LL |         (CONST1, _) | (_, Const2) => () |         ^^^^^^^^^^^       ------ variable not in all patterns |         | |         pattern doesn't bind `Const2` | help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `?::Const2` --> $DIR/resolve-inconsistent-names.rs:30:27 | LL |         (CONST1, _) | (_, Const2) => () |                           ^^^^^^ error[E0308]: mismatched types --> $DIR/resolve-inconsistent-names.rs:19:19 | LL |         (A, B) | (ref B, c) | (c, A) => () |                   ^^^^^ expected enum `E`, found &E | = note: expected type `E` found type `&E` error: aborting due to 9 previous errors </ins> <del> For more information about this error, try `rustc --explain E0408`. </del> <ins> Some errors have detailed explanations: E0308, E0408, E0409. For more information about an error, try `rustc --explain E0308`. </ins>


Question:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.

config::CrateTypeDylib | config::CrateTypeProcMacro => MetadataKind::Compressed, } <del> }).max().unwrap(); </del> <ins> }).max().unwrap_or(MetadataKind::None); </ins> if kind == MetadataKind::None { return (metadata_llcx,


Question:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: --crate-type dylib --target thumbv7em-none-eabihf // compile-pass // error-pattern: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf` #![feature(no_core)] #![no_std] #![no_core] </ins>


Question:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.

<ins> warning: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf` </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} //~^ ERROR: invalid value for constraint in inline assembly } } </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-51431.rs:7:32 | LL |         asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} |                                ^^^^ error: aborting due to previous error </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> trait A { const C: usize; fn f() -> ([u8; A::C], [u8; A::C]); //~^ ERROR: type annotations needed: cannot resolve //~| ERROR: type annotations needed: cannot resolve } fn main() {} </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:21 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                     ^^^^ error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:33 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                                 ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> trait T<'x> { type V; } impl<'g> T<'g> for u32 { type V = u16; } fn main() { (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); //~^ ERROR: type mismatch in closure arguments //~| ERROR: type mismatch resolving } </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^-----^ |     | | |     | found signature of `fn(_) -> _` |     expected signature of `for<'x> fn(<u32 as T<'x>>::V) -> _` | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error[E0271]: type mismatch resolving `for<'x> <[closure@$DIR/issue-41366.rs:10:7: 10:12] as std::ops::FnOnce<(<u32 as T<'x>>::V,)>>::Output == ()` --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^^^^^^^ expected bound lifetime parameter 'x, found concrete lifetime | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> fn main() { [(); &(&'static: loop { |x| {}; }) as *const _ as usize] //~^ ERROR: invalid label name `'static` //~| ERROR: type annotations needed } </ins>


Question:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

<ins> error: invalid label name `'static` --> $DIR/issue-52437.rs:2:13 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |             ^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52437.rs:2:30 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |                              ^ consider giving this closure parameter a type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>


Question:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

Token::Interpolated(ref nt) => may_be_ident(&nt.0), _ => false, }, <ins> "lifetime" => match *token { Token::Lifetime(_) => true, Token::Interpolated(ref nt) => match nt.0 { token::NtLifetime(_) | token::NtTT(_) => true, _ => false, }, _ => false, }, </ins> _ => match *token { token::CloseDelim(_) => false, _ => true,


Question:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

fn main() { m!(a); <del> //~^ ERROR expected a lifetime, found `a` </del> <ins> //~^ ERROR no rules expected the token `a` </ins> }


Question:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

//}}} <ins> //{{{ issue 50903 ============================================================== macro_rules! foo_50903 { ($($lif:lifetime ,)* #) => {}; } foo_50903!('a, 'b, #); foo_50903!('a, #); foo_50903!(#); //}}} //{{{ issue 51477 ============================================================== macro_rules! foo_51477 { ($lifetime:lifetime) => { "last token is lifetime" }; ($other:tt) => { "last token is other" }; ($first:tt $($rest:tt)*) => { foo_51477!($($rest)*) }; } fn test_51477() { assert_eq!("last token is lifetime", foo_51477!('a)); assert_eq!("last token is other", foo_51477!(@)); assert_eq!("last token is lifetime", foo_51477!(@ {} 'a)); } //}}} </ins> //{{{ some more tests ========================================================== macro_rules! test_block {


Question:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

test_meta_block!(windows {}); <ins> macro_rules! test_lifetime { (1. $($l:lifetime)* $($b:block)*) => {}; (2. $($b:block)* $($l:lifetime)*) => {}; } test_lifetime!(1. 'a 'b {} {}); test_lifetime!(2. {} {} 'a 'b); </ins> //}}} fn main() {


Question:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

test_40569(); test_35650(); test_24189(); <ins> test_51477(); </ins> }


Question:
When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.

// highlighted text will always be `&<expr>` and // thus can transform to `&mut` by slicing off // first ASCII character and prepending "&mut ". <del> let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); </del> <ins> if src.starts_with('&') { let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); } </ins> } }


Question:
When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(nll)] fn main() { let foo = &16; //~^ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut 16 *foo = 32; //~^ ERROR cannot assign to `*foo` which is behind a `&` reference let bar = foo; //~^ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut i32 *bar = 64; //~^ ERROR cannot assign to `*bar` which is behind a `&` reference } </ins>


Question:
When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.

<ins> error[E0594]: cannot assign to `*foo` which is behind a `&` reference --> $DIR/issue-51515.rs:17:5 | LL |     let foo = &16; |               --- help: consider changing this to be a mutable reference: `&mut 16` ... LL |     *foo = 32; |     ^^^^^^^^^ `foo` is a `&` reference, so the data it refers to cannot be written error[E0594]: cannot assign to `*bar` which is behind a `&` reference --> $DIR/issue-51515.rs:22:5 | LL |     let bar = foo; |         --- help: consider changing this to be a mutable reference: `&mut i32` ... LL |     *bar = 64; |     ^^^^^^^^^ `bar` is a `&` reference, so the data it refers to cannot be written error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0594`. </ins>


Question:
If I return a direct type that is , I get a helpful compiler warning: The equivalent (and I believe preferred) code using gives no such useful feedback: Amusingly, this isn't a new problem, as returning a boxed trait object also has the same problem. It's arguably worse there because you've performed an allocation for no good reason, but it's also less likely because people are more reluctant to introduce unneeded allocations.
Since Rust 1.27 stabilizes (on functions), one possible solution would be a lint that checks the compiler-known type underneath the and the function returning it. If the type has the annotation but the function does not, it could suggest adding the attribute to the function.
I think it would make sense for to quickly review and agree on how we should handle this. A lint seems plausible. Inside the same module, where we know the concrete underlying type, it would definitely make sense to pass through the . I'd love to know if it makes sense to automatically pass through the on the concrete type when used from outside the module, so that this can work automatically without needing a lint and a manual additional on the function.
Why is the not on, say, ?
I agree with that traits seem like the better solution here than trying to "leak" must-used-ness.
In that case, is it fine that returning an of real type will drop the must-used-ness? Maybe we should suggest to the author of the function to add the attribute to the function if the real type is
Right, there's nothing meaningfully tying such a function to , if is hidden.
The new thing being stabilized in 1.27 is specifically on functions and methods (). on types, including the iterator-adapter structs like , are .
We may need to add an arm for in this match?
So, I'd absolutely support adding for traits, which would have the same effect on a function returning as on a type T would have for a function returning . However, I also think we ought to handle this case somehow, preferably in a way that doesn't require the user to manually propagate outward on every function that returns a type.
I don't think we should. The type, including its must-use'dness, is not a part of the public API in that context. If you want the function return to be treated as must-use, the solution in that case is to tag the function as must-use.
Then in that case, would it make sense to have a lint suggesting propagation of from the type to the function that returns that concrete type?
I don't think so. The point of returning impl Trait is to hide the return type and the facts of its API, the fact that the type is must-use seems no different from other facts about the return type.
As alluded to above, I argue that this is a bug in the must-use lint due to its antedating impl-Trait; I don't see sufficient cause here to complicate the language with another lint or feature. A pull request is forthcoming.
Hm, perhaps this was too confidently worded: see description of the new pull request .
So let me summarize to see if I understand correctly what you're planning for must_use for traits:
I think expanding the applicability of mustuse should probably be introduced using an RFC. It seems to me that there are two different approaches proposed and an RFC could clarify why we chose a certain approach: proposes to evaluate the lint using the concrete type and provided a PR to this effect. This is incompatible with statement with which I agree with: "The type, including its must-use'dness, is not a part of the public API in that context [i.e. return impl Trait]". I also agree with that mustuse for traits is something we should investigate and pursue. This would be extremely helpful for futures because forgetting to poll needs to be obvious.
Can you provide an example of a case where it is the correct thing to return a concrete type that is tagged as through and not use the result of the function? My original premise is that this is an unintentional mistake in 95-99% of the cases, which feels like the ideal case for a lint. In the (rare) case where the author of the -returning function deliberately wants to allow forgetting to use the return value, they can allow the lint. I don't know exactly which "other facts" you mean, but I can think of two primary things: "sub" traits, which are not automagically propagated: traits, which are automagically propagated: I think that the case is different from the "sub trait" case because you will rather quickly run into "well, my code doesn't compile" errors when you forget to return the "sub trait". You then have to decide if you meant to expose that interface. I know the auto trait aspect was much discussed, so I don't wish to re-litigate it. My point here is that we : I think there's a case to be made that is already an ergonomics-based feature as it helps prevent the user from writing code they didn't mean to.
As a concrete side note, I opened this because I did it myself: I wrote some code that returned and was confused for a minute because the compiler didn't have any warnings. I'm used to those warnings and they are part of my development flow. Having them "suddenly go missing" just because I wanted to use felt like trying to step on the last stair that isn't there. For me, it's right up there with in that my "normal" flow of programming that I've established since ~Rust 0.12 doesn't quite work the same with .
IMO the more conservative approach would be to not leak mustuse on the concrete type. If that turns out to be the wrong call, it can always be later. I think defining mustuse on traits (e.g. on and ) will already be enough to catch all the bugs we're trying to prevent. The big advantage of defining mustuse on the trait is that this system can also work for unnameable types like the return type of an async function. Additionally it also avoids all the boilerplate code that defines each concrete iterator or future type as muchuse.
I think the current approach of "stick on the dozens of types implementing and " just doesn't scale and this is an example where it goes wrong. Also consider type parameters or associated types that are known implement those traits. IMO they should get the same treatment by , without knowing the concrete type.
To be clear, I'm totally happy with implementing for traits, but that particular option has been available "forever" but doesn't seem to be implemented for whichever reason. On the flip side, fairly quickly. I really just don't want to see this particular feature held up by a months (years?) long discussion of the ideal Platonic implementation of for traits. Isn't that what the current implementation does? Am I missing something? I believe that's what I'm proposing... Yes, I believe that that's a better option, and I'll add one more: presumably it will also work for trait objects. I just don't want to lose what existing ergonomics we have until someone implements for traits. These don't even have to be mutually exclusive options! The lint can catch cases that a trait wouldn't — such as when a given instance of a trait should be must use but not the trait itself. The lint could even be removed once the better solution is created, if we felt it didn't carry its weight anymore.
I also want to suggest a more aggressive approach: existential is always no matter of its underlying type. If a function is returning an thing, you were probably meant to use it in some way.
I wonder how hard it would be to turn such a thing on to see the impact.
Thanks for the compelling argument! I agree with what I think is the implication of your post: this question boils down to "Is more like an auto trait, or a regular API fact?" I'm not sure of the answer. What is the distinction with vs any other return type? Isn't it plausible that something that returns also has a useful side effect, and the return is not relevant all the time?

} let t = cx.tables.expr_ty(&expr); <del> // FIXME(varkor): replace with `t.is_unit() || t.conservative_is_uninhabited()`. let type_permits_no_use = match t.sty { ty::Tuple(ref tys) if tys.is_empty() => true, ty::Never => true, ty::Adt(def, _) => { if def.variants.is_empty() { true } else { check_must_use(cx, def.did, s.span, "") </del> <ins> let type_permits_lack_of_use = if t.is_unit() || cx.tcx.is_ty_uninhabited_from(cx.tcx.hir.get_module_parent(expr.id), t) { true } else { match t.sty { ty::Adt(def, _) => check_must_use(cx, def.did, s.span, "", ""), ty::Opaque(def, _) => { let mut must_use = false; for (predicate, _) in &cx.tcx.predicates_of(def).predicates { if let ty::Predicate::Trait(ref poly_trait_predicate) = predicate { let trait_ref = poly_trait_predicate.skip_binder().trait_ref; if check_must_use(cx, trait_ref.def_id, s.span, "implementer of ", "") { must_use = true; break; } } } must_use } ty::Dynamic(binder, _) => { let mut must_use = false; for predicate in binder.skip_binder().iter() { if let ty::ExistentialPredicate::Trait(ref trait_ref) = predicate { if check_must_use(cx, trait_ref.def_id, s.span, "", " trait object") { must_use = true; break; } } } must_use </ins> } <ins> _ => false, </ins> } <del> _ => false, </del> }; let mut fn_warned = false;