Question:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>


Question:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

<ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>


Question:
Unit tests should not be doing multi-second sleeps as this is bad for turnaround during development.
Fair enough, I will try to get around to looking at this.
Done.

use libc; use option::None; use os; <del> use path::Path; </del> use run::{readclose, writeclose}; use run;


Question:
Unit tests should not be doing multi-second sleeps as this is bad for turnaround during development.
Fair enough, I will try to get around to looking at this.
Done.

p.destroy(); // ...and nor should this (and nor should the destructor) } <del> #[cfg(unix)] // there is no way to sleep on windows from inside libcore... </del> fn test_destroy_actually_kills(force: bool) { <del> let path = Path(fmt!("test/core-run-test-destroy-actually-kills-%?.tmp", force)); os::remove_file(&path); </del> <ins> #[cfg(unix)] static BLOCK_COMMAND: &'static str = "cat"; </ins> <del> let cmd = fmt!("sleep 5 && echo MurderDeathKill > %s", path.to_str()); let mut p = run::start_program("sh", [~"-c", cmd]); </del> <ins> #[cfg(windows)] static BLOCK_COMMAND: &'static str = "cmd"; </ins> <del> p.destroy(); // destroy the program before it has a chance to echo its message </del> <ins> #[cfg(unix)] fn process_exists(pid: libc::pid_t) -> bool { run::program_output("ps", [~"-p", pid.to_str()]).out.contains(pid.to_str()) } </ins> <del> unsafe { // wait to ensure the program is really destroyed and not just waiting itself libc::sleep(10); </del> <ins> #[cfg(windows)] fn process_exists(pid: libc::pid_t) -> bool { use libc::types::os::arch::extra::DWORD; use libc::funcs::extra::kernel32::{CloseHandle, GetExitCodeProcess, OpenProcess}; use libc::consts::os::extra::{FALSE, PROCESS_QUERY_INFORMATION, STILL_ACTIVE }; unsafe { let proc = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid as DWORD); if proc.is_null() { return false; } // proc will be non-null if the process is alive, or if it died recently let mut status = 0; GetExitCodeProcess(proc, &mut status); CloseHandle(proc); return status == STILL_ACTIVE; } </ins> } <del> // the program should not have had chance to echo its message assert!(!path.exists()); </del> <ins> // this program will stay alive indefinitely trying to read from stdin let mut p = run::start_program(BLOCK_COMMAND, []); assert!(process_exists(p.get_id())); if force { p.force_destroy(); } else { p.destroy(); } assert!(!process_exists(p.get_id())); </ins> } #[test] <del> #[cfg(unix)] </del> fn test_unforced_destroy_actually_kills() { test_destroy_actually_kills(false); } #[test] <del> #[cfg(unix)] </del> fn test_forced_destroy_actually_kills() { test_destroy_actually_kills(true); }


Question:
Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:

<ins> // This previously triggered an ICE. pub(in crate::r#mod) fn main() {} //~^ ERROR expected module, found unresolved item </ins>


Question:
Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:

<ins> error[E0577]: expected module, found unresolved item `crate::r#mod` --> $DIR/issue-61732.rs:3:8 | LL | pub(in crate::r#mod) fn main() {} |        ^^^^^^^^^^^^ not a module error: Compilation failed, aborting rustdoc error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0577`. </ins>


Question:
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!

let mut indirect_outputs = vec![]; for (i, (out, &place)) in ia.outputs.iter().zip(&outputs).enumerate() { if out.is_rw { <del> inputs.push(self.load_operand(place).immediate()); </del> <ins> let operand = self.load_operand(place); if let OperandValue::Immediate(_) = operand.val { inputs.push(operand.immediate()); } </ins> ext_constraints.push(i.to_string()); } if out.is_indirect { <del> indirect_outputs.push(self.load_operand(place).immediate()); </del> <ins> let operand = self.load_operand(place); if let OperandValue::Immediate(_) = operand.val { indirect_outputs.push(operand.immediate()); } </ins> } else { output_types.push(place.layout.llvm_type(self.cx())); }


Question:
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!

<ins> // build-fail // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm!("nop" : "+r"("r15")); //~^ malformed inline assembly } } </ins>


Question:
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!

<ins> error[E0668]: malformed inline assembly --> $DIR/issue-62046.rs:8:9 | LL |         asm!("nop" : "+r"("r15")); |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0668`. </ins>


Question:
Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?

id: AllocId, liveness: AllocCheck, ) -> InterpResult<'static, (Size, Align)> { <del> // Regular allocations. if let Ok(alloc) = self.get(id) { return Ok((Size::from_bytes(alloc.bytes.len() as u64), alloc.align)); } // Function pointers. if let Ok(_) = self.get_fn_alloc(id) { return if let AllocCheck::Dereferencable = liveness { // The caller requested no function pointers. err!(DerefFunctionPointer) } else { Ok((Size::ZERO, Align::from_bytes(1).unwrap())) }; } // Foreign statics. // Can't do this in the match argument, we may get cycle errors since the lock would // be held throughout the match. let alloc = self.tcx.alloc_map.lock().get(id); match alloc { Some(GlobalAlloc::Static(did)) => { assert!(self.tcx.is_foreign_item(did)); // Use size and align of the type let ty = self.tcx.type_of(did); let layout = self.tcx.layout_of(ParamEnv::empty().and(ty)).unwrap(); return Ok((layout.size, layout.align.abi)); </del> <ins> // Don't use `self.get` here as that will // a) cause cycles in case `id` refers to a static // b) duplicate a static's allocation in miri match self.alloc_map.get_or(id, || Err(())) { Ok((_, alloc)) => Ok((Size::from_bytes(alloc.bytes.len() as u64), alloc.align)), Err(()) => { // Not a local allocation, check the global `tcx.alloc_map`. // Can't do this in the match argument, we may get cycle errors since the lock would // be held throughout the match. let alloc = self.tcx.alloc_map.lock().get(id); match alloc { Some(GlobalAlloc::Static(did)) => { // Use size and align of the type. let ty = self.tcx.type_of(did); let layout = self.tcx.layout_of(ParamEnv::empty().and(ty)).unwrap(); Ok((layout.size, layout.align.abi)) }, Some(GlobalAlloc::Memory(alloc)) => // Need to duplicate the logic here, because the global allocations have // different associated types than the interpreter-local ones. Ok((Size::from_bytes(alloc.bytes.len() as u64), alloc.align)), Some(GlobalAlloc::Function(_)) => { if let AllocCheck::Dereferencable = liveness { // The caller requested no function pointers. err!(DerefFunctionPointer) } else { Ok((Size::ZERO, Align::from_bytes(1).unwrap())) } }, // The rest must be dead. None => if let AllocCheck::MaybeDead = liveness { // Deallocated pointers are allowed, we should be able to find // them in the map. Ok(*self.dead_alloc_map.get(&id) .expect("deallocated pointers should all be recorded in  `dead_alloc_map`")) } else { err!(DanglingPointerDeref) }, } </ins> } <del> _ => {} } // The rest must be dead. if let AllocCheck::MaybeDead = liveness { // Deallocated pointers are allowed, we should be able to find // them in the map. Ok(*self.dead_alloc_map.get(&id) .expect("deallocated pointers should all be recorded in `dead_alloc_map`")) } else { err!(DanglingPointerDeref) </del> } }


Question:
Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?

<ins> // check-pass struct Foo { foo: Option<&'static Foo> } static FOO: Foo = Foo { foo: Some(&FOO), }; fn main() {} </ins>


Question:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to

debug!("late_bound_in_ty = {:?}", late_bound_in_ty); for br in late_bound_in_ty.difference(&late_bound_in_trait_ref) { let br_name = match *br { <del> ty::BrNamed(_, name) => name, _ => { span_bug!( binding.span, "anonymous bound region {:?} in binding but not trait ref", br ); } </del> <ins> ty::BrNamed(_, name) => format!("lifetime `{}`", name), _ => "an anonymous lifetime".to_string(), </ins> }; // FIXME: point at the type params that don't have appropriate lifetimes: // struct S1<F: for<'a> Fn(&i32, &i32) -> &'a i32>(F); //                         ----  ----     ^^^^^^^ <del> struct_span_err!( </del> <ins> let mut err = struct_span_err!( </ins> tcx.sess, binding.span, E0582, <del> "binding for associated type `{}` references lifetime `{}`,  </del> <ins> "binding for associated type `{}` references {},  </ins> which does not appear in the trait input types", binding.item_name, br_name <del> ) .emit(); </del> <ins> ); if let ty::BrAnon(_) = *br { // The only way for an anonymous lifetime to wind up // in the return type but **also** be unconstrained is // if it only appears in "associated types" in the // input. See #62200 for an example. In this case, // though we can easily give a hint that ought to be // relevant. err.note("lifetimes appearing in an associated type are not considered constrained"); } err.emit(); </ins> } } }


Question:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to

<ins> struct S {} trait T<'a> { type A; } impl T<'_> for S { type A = u32; } fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} //~^ ERROR binding for associated type `Output` references an anonymous lifetime //~^^ NOTE lifetimes appearing in an associated type are not considered constrained fn main() {} </ins>


Question:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to

<ins> error[E0582]: binding for associated type `Output` references an anonymous lifetime, which does not appear in the trait input types --> $DIR/issue-62200.rs:11:39 | LL | fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} |                                       ^^^^^^^^^^^^^^^ | = note: lifetimes appearing in an associated type are not considered constrained error: aborting due to previous error For more information about this error, try `rustc --explain E0582`. </ins>


Question:
I have the following code: Attempting to use this function, such as in the following manner: causes the compiler to crash with the following backtrace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this was fixed at some point. The following minimal example ICEs on nightly-2019-06-26, but doesn't on nightly-2020-03-11!
I'll look into adding a test for this tomorrow! :)
assign

<ins> // build-pass #![allow(incomplete_features)] #![feature(const_generics)] pub struct Vector<T, const N: usize>([T; N]); pub type TruncatedVector<T, const N: usize> = Vector<T, { N - 1 }>; impl<T, const N: usize> Vector<T, { N }> { /// Drop the last component and return the vector with one fewer dimension. pub fn trunc(self) -> (TruncatedVector<T, { N }>, T) { unimplemented!() } } fn vec4<T>(a: T, b: T, c: T, d: T) -> Vector<T, 4> { Vector([a, b, c, d]) } fn main() { let (_xyz, _w): (TruncatedVector<u32, 4>, u32) = vec4(0u32, 1, 2, 3).trunc(); } </ins>


Question:
Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.

<ins> enum A { Value(()) } fn main() { let a = A::Value(()); a == A::Value; //~^ ERROR binary operation `==` cannot be applied to type `A` } </ins>


Question:
Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.

<ins> error[E0369]: binary operation `==` cannot be applied to type `A` --> $DIR/issue-62375.rs:7:7 | LL |     a == A::Value; |     - ^^ -------- fn(()) -> A {A::Value} |     | |     A | = note: an implementation of `std::cmp::PartialEq` might be missing for `A` error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. </ins>


Question:
(and by extension ) have as the mask type, but the lists as the mask type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hey I (I think we all) very much appreciate the work you are doing by looking at the docs and finding unsound things. What about opening a PR and fixing them immediatly (some of them could be done by using the github editor)? It's a very great opportunity to make Rust a better programming langauge. If you feel like it, please open a PR and reference this issue with one of the github provides.
I am well aware of how GitHub works :D unfortunately for us all, I only have so much programming time. I've been busy at work safe wrapping all these intrinsics for my own lib, which is why I'm filing bugs on them as they come up. However, in my experience, filing even a single PR to this repo is rather involved and so I've mostly given up on doing it. As to this particular issue, it's a change to a stable API, so at minimum a full crater run would have to be performed of course. The input mask value has to be a const, so you get a lot of literals of course and those can usually infer to the new type fine, but you also get a lot of const declarations too, which would break. I suspect that at least some people will get their code broken. Given that the intrinsic only uses the 8 lowest bits, it would be entirely reasonable for T-libs to say they don't care about the i32/u32 difference compared to code breaks and just document the (very minor) difference. or they could go for absolute exactness and declare the breaks to be the fair product of a bug fix. up to them
I believe this was changed recently because Intel's definition is wrong/inconsistent. See
ah lovely. of course the guide is wrong :P well, then consider this a minor documentation issue. the function should simply explain that it doesn't match the spec and why and such.
I could take this! claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
claim
I have submitted in order to fix this. I believe we could resolve this issue once that PR is merged by updating the submodule.

<del> Subproject commit 311d56cd91609c1c1c0370cbd2ece8e3048653a5 </del> <ins> Subproject commit d6822f9c433bd70f786b157f17beaf64ee28d83a </ins>


Question:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

let mut align = if pack.is_some() { dl.i8_align } else { dl.aggregate_align }; <del> let mut sized = true; let mut offsets = vec![Size::ZERO; fields.len()]; </del> let mut inverse_memory_index: Vec<u32> = (0..fields.len() as u32).collect(); let mut optimize = !repr.inhibit_struct_field_reordering_opt();


Question:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

// At the bottom of this function, we invert `inverse_memory_index` to // produce `memory_index` (see `invert_mapping`). <ins> let mut sized = true; let mut offsets = vec![Size::ZERO; fields.len()]; </ins> let mut offset = Size::ZERO; let mut largest_niche = None; let mut largest_niche_available = 0;


Question:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

let count = (niche_variants.end().as_u32() - niche_variants.start().as_u32() + 1) as u128; <del> // FIXME(#62691) use the largest niche across all fields, // not just the first one. for (field_index, &field) in variants[i].iter().enumerate() { let niche = match &field.largest_niche { Some(niche) => niche, _ => continue, }; let (niche_start, niche_scalar) = match niche.reserve(self, count) { Some(pair) => pair, None => continue, }; </del> <ins> // Find the field with the largest niche let niche_candidate = variants[i] .iter() .enumerate() .filter_map(|(j, &field)| Some((j, field.largest_niche.as_ref()?))) .max_by_key(|(_, niche)| niche.available(dl)); if let Some((field_index, niche, (niche_start, niche_scalar))) = niche_candidate.and_then(|(field_index, niche)| { Some((field_index, niche, niche.reserve(self, count)?)) }) { </ins> let mut align = dl.aggregate_align; let st = variants .iter_enumerated()


Question:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

C, } <ins> enum Option2<A, B> { Some(A, B), None } </ins> pub fn main() { assert_eq!(size_of::<u8>(), 1 as usize); assert_eq!(size_of::<u32>(), 4 as usize);


Question:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

assert_eq!(size_of::<Option<Option<(bool, &())>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option<(&(), bool)>>>(), size_of::<(bool, &())>()); <ins> assert_eq!(size_of::<Option<Option2<bool, &()>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option2<&(), bool>>>(), size_of::<(bool, &())>()); </ins> }


Question:
This may or may not have the same fix as , but the LinuxTools PR builder doesn't have access to the same variables as the auto builders, which means the docker image fails at the very end () with an undefined env var.
cc

pr: - master <ins> variables: - group: public-credentials </ins> jobs: - job: Linux timeoutInMinutes: 600


Question:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+strict-align,+v6,+vfp2".to_string(), </del> <ins> features: "+strict-align,+v6,+vfp2,-d32".to_string(), </ins> abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "u{1}__gnu_mcount_nc".to_string(), .. base


Question:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

// Most of these settings are copied from the arm_unknown_linux_gnueabihf // target. <del> base.features = "+strict-align,+v6,+vfp2".to_string(); </del> <ins> base.features = "+strict-align,+v6,+vfp2,-d32".to_string(); </ins> base.max_atomic_width = Some(64); Ok(Target { // It's important we use "gnueabihf" and not "musleabihf" here. LLVM


Question:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+v6,+vfp2".to_string(), </del> <ins> features: "+v6,+vfp2,-d32".to_string(), </ins> max_atomic_width: Some(64), abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "u{1}__gnu_mcount_nc".to_string(),


Question:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+v6,+vfp2".to_string(), </del> <ins> features: "+v6,+vfp2,-d32".to_string(), </ins> abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "__mcount".to_string(), .. base


Question:
As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).

ItemType::Enum, ItemType::Constant, ItemType::Static, ItemType::Trait, ItemType::Function, ItemType::Typedef, ItemType::Union, ItemType::Impl, ItemType::TyMethod, ItemType::Method, ItemType::StructField, ItemType::Variant,  ItemType::AssocType, ItemType::AssocConst, ItemType::ForeignType] {   ItemType::AssocType, ItemType::AssocConst, ItemType::ForeignType, ItemType::Keyword] {  if items.iter().any(|it| !it.is_stripped() && it.type_() == myty) { let (short, name) = item_ty_to_strs(&myty); sidebar.push_str(&format!("
{name}
",


Question:
As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).

// @has foo/index.html '//h2[@id="keywords"]' 'Keywords' // @has foo/index.html '//a[@href="keyword.match.html"]' 'match' <ins> // @has foo/index.html '//div[@class="block items"]//a/@href' '#keywords' </ins> // @has foo/keyword.match.html '//a[@class="keyword"]' 'match' // @has foo/keyword.match.html '//span[@class="in-band"]' 'Keyword match' // @has foo/keyword.match.html '//section[@id="main"]//div[@class="docblock"]//p' 'this is a test!'


Question:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

_ => false, } } <ins> /// This can happen for `async fn`, e.g. `async fn f<'_>(&'_ self)`. /// /// See [`lifetime_to_generic_param`] in [`rustc_ast_lowering`] for more information. /// /// [`lifetime_to_generic_param`]: rustc_ast_lowering::LoweringContext::lifetime_to_generic_param fn is_elided_lifetime(param: &hir::GenericParam<'_>) -> bool { match param.kind { hir::GenericParamKind::Lifetime { kind: hir::LifetimeParamKind::Elided } => true, _ => false, } } </ins> let impl_trait_params = self .params .iter()


Question:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

.collect::<Vec<_>>(); let mut params = Vec::with_capacity(self.params.len()); <del> for p in self.params.iter().filter(|p| !is_impl_trait(p)) { </del> <ins> for p in self.params.iter().filter(|p| !is_impl_trait(p) && !is_elided_lifetime(p)) { </ins> let p = p.clean(cx); params.push(p); }


Question:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

TyKind::Never => Never, TyKind::Ptr(ref m) => RawPointer(m.mutbl, box m.ty.clean(cx)), TyKind::Rptr(ref l, ref m) => { <del> let lifetime = if l.is_elided() { None } else { Some(l.clean(cx)) }; </del> <ins> // There are two times a `Fresh` lifetime can be created: // 1. For `&'_ x`, written by the user. This corresponds to `lower_lifetime` in `rustc_ast_lowering`. // 2. For `&x` as a parameter to an `async fn`. This corresponds to `elided_ref_lifetime in `rustc_ast_lowering`. //    See #59286 for more information. // Ideally we would only hide the `'_` for case 2., but I don't know a way to distinguish it. // Turning `fn f(&'_ self)` into `fn f(&self)` isn't the worst thing in the world, though; // there's no case where it could cause the function to fail to compile. let elided = l.is_elided() || matches!(l.name, LifetimeName::Param(ParamName::Fresh(_))); let lifetime = if elided { None } else { Some(l.clean(cx)) }; </ins> BorrowedRef { lifetime, mutability: m.mutbl, type_: box m.ty.clean(cx) } } TyKind::Slice(ref ty) => Slice(box ty.clean(cx)),


Question:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

<ins> // ignore-tidy-linelength </ins> // edition:2018 #![feature(min_const_generics)]


Question:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

pub async fn mut_self(mut self, mut first: usize) {} } <ins> pub trait Pattern<'a> {} </ins> pub trait Trait<const N: usize> {} // @has async_fn/fn.const_generics.html // @has - '//pre[@class="rust fn"]' 'pub async fn const_generics<const N: usize>(_: impl Trait<N>)' pub async fn const_generics<const N: usize>(_: impl Trait<N>) {} <ins> // test that elided lifetimes are properly elided and not displayed as `'_` // regression test for #63037 // @has async_fn/fn.elided.html // @has - '//pre[@class="rust fn"]' 'pub async fn elided(foo: &str) -> &str' pub async fn elided(foo: &str) -> &str {} // This should really be shown as written, but for implementation reasons it's difficult. // See `impl Clean for TyKind::Rptr`. // @has async_fn/fn.user_elided.html // @has - '//pre[@class="rust fn"]' 'pub async fn user_elided(foo: &str) -> &str' pub async fn user_elided(foo: &'_ str) -> &str {} // @has async_fn/fn.static_trait.html // @has - '//pre[@class="rust fn"]' 'pub async fn static_trait(foo: &str) -> Box<dyn Bar>' pub async fn static_trait(foo: &str) -> Box<dyn Bar> {} // @has async_fn/fn.lifetime_for_trait.html // @has - '//pre[@class="rust fn"]' "pub async fn lifetime_for_trait(foo: &str) -> Box<dyn Bar + '_>" pub async fn lifetime_for_trait(foo: &str) -> Box<dyn Bar + '_> {} // @has async_fn/fn.elided_in_input_trait.html // @has - '//pre[@class="rust fn"]' "pub async fn elided_in_input_trait(t: impl Pattern<'_>)" pub async fn elided_in_input_trait(t: impl Pattern<'_>) {} struct AsyncFdReadyGuard<'a, T> { x: &'a T } impl Foo { // @has async_fn/struct.Foo.html // @has - '//h4[@class="method"]' 'pub async fn complicated_lifetimes( &self, context: &impl Bar) -> impl Iterator<Item = &usize>' pub async fn complicated_lifetimes(&self, context: &impl Bar) -> impl Iterator<Item = &usize> {} // taken from `tokio` as an example of a method that was particularly bad before // @has - '//h4[@class="method"]' "pub async fn readable<T>(&self) -> Result<AsyncFdReadyGuard<'_, T>, ()>" pub async fn readable<T>(&self) -> Result<AsyncFdReadyGuard<'_, T>, ()> {} // @has - '//h4[@class="method"]' "pub async fn mut_self(&mut self)" pub async fn mut_self(&mut self) {} } // test named lifetimes, just in case // @has async_fn/fn.named.html // @has - '//pre[@class="rust fn"]' "pub async fn named<'a, 'b>(foo: &'a str) -> &'b str" pub async fn named<'a, 'b>(foo: &'a str) -> &'b str {} // @has async_fn/fn.named_trait.html // @has - '//pre[@class="rust fn"]' "pub async fn named_trait<'a, 'b>(foo: impl Pattern<'a>) -> impl Pattern<'b>" pub async fn named_trait<'a, 'b>(foo: impl Pattern<'a>) -> impl Pattern<'b> {} </ins>


Question:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

pub(super) fn recover_parens_around_for_head( &mut self, pat: P<Pat>, <del> expr: &Expr, </del> begin_paren: Option<Span>, ) -> P<Pat> { match (&self.token.kind, begin_paren) { (token::CloseDelim(token::Paren), Some(begin_par_sp)) => { self.bump(); <del> let pat_str = self // Remove the `(` from the span of the pattern: .span_to_snippet(pat.span.trim_start(begin_par_sp).unwrap()) .unwrap_or_else(|_| pprust::pat_to_string(&pat)); self.struct_span_err(self.prev_token.span, "unexpected closing `)`") .span_label(begin_par_sp, "opening `(`") .span_suggestion( begin_par_sp.to(self.prev_token.span), "remove parenthesis in `for` loop", format!("{} in {}", pat_str, pprust::expr_to_string(&expr)), // With e.g. `for (x) in y)` this would replace `(x) in y)` // with `x) in y)` which is syntactically invalid. // However, this is prevented before we get here. Applicability::MachineApplicable, ) .emit(); </del> <ins> self.struct_span_err( MultiSpan::from_spans(vec![begin_par_sp, self.prev_token.span]), "unexpected parenthesis surrounding `for` loop head", ) .multipart_suggestion( "remove parenthesis in `for` loop", vec![(begin_par_sp, String::new()), (self.prev_token.span, String::new())], // With e.g. `for (x) in y)` this would replace `(x) in y)` // with `x) in y)` which is syntactically invalid. // However, this is prevented before we get here. Applicability::MachineApplicable, ) .emit(); </ins> // Unwrap `(pat)` into `pat` to avoid the `unused_parens` lint. pat.and_then(|pat| match pat.kind {


Question:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

self.check_for_for_in_in_typo(self.prev_token.span); let expr = self.parse_expr_res(Restrictions::NO_STRUCT_LITERAL, None)?; <del> let pat = self.recover_parens_around_for_head(pat, &expr, begin_paren); </del> <ins> let pat = self.recover_parens_around_for_head(pat, begin_paren); </ins> let (iattrs, loop_block) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs);


Question:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

for ( elem in vec ) { //~^ ERROR expected one of `)`, `,`, `@`, or `|`, found keyword `in` <del> //~| ERROR unexpected closing `)` </del> <ins> //~| ERROR unexpected parenthesis surrounding `for` loop head </ins> const RECOVERY_WITNESS: () = 0; //~ ERROR mismatched types } }


Question:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

LL |     for ( elem in vec ) { |                ^^ expected one of `)`, `,`, `@`, or `|` <del> error: unexpected closing `)` --> $DIR/recover-for-loop-parens-around-head.rs:10:23 </del> <ins> error: unexpected parenthesis surrounding `for` loop head --> $DIR/recover-for-loop-parens-around-head.rs:10:9 </ins> | LL |     for ( elem in vec ) { <del> |         --------------^ |         | |         opening `(` |         help: remove parenthesis in `for` loop: `elem in vec` </del> <ins> |         ^             ^ | help: remove parenthesis in `for` loop | LL -     for ( elem in vec ) { LL +     for  elem in vec  { | </ins> error[E0308]: mismatched types --> $DIR/recover-for-loop-parens-around-head.rs:13:38


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

kind_name = "variant"; } None => { <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { </ins> fmt!("mismatched types: expected `%s` but found %s", <del> resolved_expected, actual)}, ~"a structure pattern", </del> <ins> e, actual)})}, Some(expected), ~"a structure pattern", </ins> None); fcx.write_error(pat.id); kind_name = "[error]";


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

kind_name = "structure"; } _ => { <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { </ins> fmt!("mismatched types: expected `%s` but found %s", <del> resolved_expected, actual)}, ~"an enum or structure pattern", </del> <ins> e, actual)})}, Some(expected), ~"an enum or structure pattern", </ins> None); fcx.write_error(pat.id); kind_name = "[error]";


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

for elts.each |elt| { check_pat(pcx, *elt, ty::mk_err()); } <del> let actual = ty::mk_tup(tcx, elts.map(|pat_var| { fcx.node_ty(pat_var.id) })); </del> // use terr_tuple_size if both types are tuples let type_error = match s { ty::ty_tup(ref ex_elts) =>


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

found: e_count}), _ => ty::terr_mismatch }; <del> fcx.infcx().report_mismatched_types(pat.span, expected, actual, &type_error); </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), ~"tuple", Some(&type_error)); </ins> fcx.write_error(pat.id); } }


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

for after.each |&elt| { check_pat(pcx, elt, ty::mk_err()); } <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { fmt!("mismatched types: expected `%s` but found %s", resolved_expected, actual)}, ~"a vector pattern", None); </del> <ins> fcx.infcx().type_error_message_str_with_expected( pat.span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), ~"a vector pattern", None); </ins> fcx.write_error(pat.id); return; }


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

} _ => { check_pat(pcx, inner, ty::mk_err()); <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(span, |actual| { fmt!("mismatched types: expected `%s` but found %s", resolved_expected, actual)}, fmt!("%s pattern", match pointer_kind { Managed => "an @-box", Owned => "a ~-box", Borrowed => "an &-pointer" }), None); </del> <ins> fcx.infcx().type_error_message_str_with_expected( span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), fmt!("%s pattern", match pointer_kind { Managed => "an @-box", Owned => "a ~-box", Borrowed => "an &-pointer" }), None); </ins> fcx.write_error(pat_id); } }


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

} } <ins> fn type_error_message_str(@mut self, sp: span, mk_msg: &fn(Option<~str>, ~str) -> ~str, actual_ty: ~str, err: Option<&ty::type_err>) { self.type_error_message_str_with_expected(sp, mk_msg, None, actual_ty, err) } fn type_error_message_str_with_expected(@mut self, sp: span, mk_msg: &fn(Option<~str>, ~str) -> ~str, expected_ty: Option<ty::t>, actual_ty: ~str, err: Option<&ty::type_err>) { debug!("hi! expected_ty = %?, actual_ty = %s", expected_ty, actual_ty); </ins> <del> fn type_error_message_str(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ~str, err: Option<&ty::type_err>) { </del> let error_str = err.map_default(~"", |t_err| fmt!(" (%s)", ty::type_err_to_str(self.tcx, *t_err))); <del> self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(actual_ty), error_str)); for err.each |err| { ty::note_and_explain_type_err(self.tcx, *err) </del> <ins> let resolved_expected = expected_ty.map(|&e_ty| { self.resolve_type_vars_if_possible(e_ty) }); if !resolved_expected.map_default(false, |&e| { ty::type_is_error(e) }) { match resolved_expected { None => self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(None, actual_ty), error_str)), Some(e) => { self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(Some(self.ty_to_str(e)), actual_ty), error_str)); } } for err.each |err| { ty::note_and_explain_type_err(self.tcx, *err) } </ins> } } <del> fn type_error_message(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ty::t, err: Option<&ty::type_err>) { </del> <ins> fn type_error_message(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ty::t, err: Option<&ty::type_err>) { </ins> let actual_ty = self.resolve_type_vars_if_possible(actual_ty); // Don't report an error if actual type is ty_err.


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

return; } <del> self.type_error_message_str(sp, mk_msg, self.ty_to_str(actual_ty), err); </del> <ins> self.type_error_message_str(sp, |_e, a| { mk_msg(a) }, self.ty_to_str(actual_ty), err); </ins> } fn report_mismatched_types(@mut self, sp: span, e: ty::t, a: ty::t,


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

} match (true, false) { <del> (true, false, false) => () //~ ERROR mismatched types: expected `(bool,bool)` but found `(bool,bool,bool)` (expected a tuple with 2 elements but found one with 3 elements) </del> <ins> (true, false, false) => () //~ ERROR mismatched types: expected `(bool,bool)` but found tuple (expected a tuple with 2 elements but found one with 3 elements) </ins> } match (true, false) {


Question:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in

<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let (x, y) = (); //~ ERROR expected `()` but found tuple (types differ) return x; } </ins>  No newline at end of file


Question:
libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .

) -> Bx::Value { let is_float = input_ty.is_floating_point(); let is_signed = input_ty.is_signed(); <del> let is_unit = input_ty.is_unit(); </del> match op { mir::BinOp::Add => if is_float { bx.fadd(lhs, rhs)


Question:
libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .

mir::BinOp::Shl => common::build_unchecked_lshift(bx, lhs, rhs), mir::BinOp::Shr => common::build_unchecked_rshift(bx, input_ty, lhs, rhs), mir::BinOp::Ne | mir::BinOp::Lt | mir::BinOp::Gt | <del> mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => if is_unit { bx.cx().const_bool(match op { mir::BinOp::Ne | mir::BinOp::Lt | mir::BinOp::Gt => false, mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => true, _ => unreachable!() }) } else if is_float { </del> <ins> mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => if is_float { </ins> bx.fcmp( base::bin_op_to_fcmp_predicate(op.to_hir_binop()), lhs, rhs


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri fix at

<del> Subproject commit 4f6f264c305ea30f1de90ad0c2f341e84d972b2e </del> <ins> Subproject commit d77fe6c63ca4c50b207a1161def90c9e57368d5b </ins>


Question:
The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.

self.is_keyword_ahead(1, &[ kw::Impl, kw::Const, <ins> kw::Async, </ins> kw::Fn, kw::Unsafe, kw::Extern,


Question:
The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.

<ins> // Ensure that `default async fn` will parse. // See issue #63716 for details. // check-pass // edition:2018 #![feature(specialization)] fn main() {} #[cfg(FALSE)] impl Foo for Bar { default async fn baz() {} } </ins>


Question: has been renamed to as discussed in , but the old name is still referenced in the docs:

/// [`len`]: #method.len /// /// Note: This example shows the internals of `&str`. `unsafe` should not be <del> /// used to get a string slice under normal circumstances. Use `as_slice` </del> <ins> /// used to get a string slice under normal circumstances. Use `as_str` </ins> /// instead. #[stable(feature = "rust1", since = "1.0.0")] mod prim_str { }


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

<ins> use rustc_data_structures::fx::FxHashMap; </ins> use syntax_pos::Span; use crate::print::pprust::token_to_string;


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

unmatched_braces: Vec::new(), matching_delim_spans: Vec::new(), last_unclosed_found_span: None, <ins> last_delim_empty_block_spans: FxHashMap::default() </ins> }; let res = tt_reader.parse_all_token_trees(); (res, tt_reader.unmatched_braces)


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

/// Used only for error recovery when arriving to EOF with mismatched braces. matching_delim_spans: Vec<(token::DelimToken, Span, Span)>, last_unclosed_found_span: Option<Span>, <ins> last_delim_empty_block_spans: FxHashMap<token::DelimToken, Span> </ins> } impl<'a> TokenTreesReader<'a> {


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

// Correct delimiter. token::CloseDelim(d) if d == delim => { let (open_brace, open_brace_span) = self.open_braces.pop().unwrap(); <ins> let close_brace_span = self.token.span; if tts.is_empty() { let empty_block_span = open_brace_span.to(close_brace_span); self.last_delim_empty_block_spans.insert(delim, empty_block_span); } </ins> if self.open_braces.len() == 0 { // Clear up these spans to avoid suggesting them as we've found // properly matched delimiters so far for an entire block. self.matching_delim_spans.clear(); } else { self.matching_delim_spans.push( <del> (open_brace, open_brace_span, self.token.span), </del> <ins> (open_brace, open_brace_span, close_brace_span), </ins> ); } // Parse the close delimiter.


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

tts.into() ).into()) }, <del> token::CloseDelim(_) => { </del> <ins> token::CloseDelim(delim) => { </ins> // An unexpected closing delimiter (i.e., there is no // matching opening delimiter). let token_str = token_to_string(&self.token); let msg = format!("unexpected close delimiter: `{}`", token_str); let mut err = self.string_reader.sess.span_diagnostic .struct_span_err(self.token.span, &msg); <ins> if let Some(span) = self.last_delim_empty_block_spans.remove(&delim) { err.span_label( span, "this block is empty, you might have not meant to close it" ); } </ins> err.span_label(self.token.span, "unexpected close delimiter"); Err(err) },


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

} /// A delimiter token. <del> #[derive(Clone, PartialEq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)] </del> <ins> #[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)] </ins> pub enum DelimToken { /// A round parenthesis (i.e., `(` or `)`). Paren,


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

<ins> fn main() { } let _ = (); } //~ ERROR unexpected close delimiter </ins>


Question:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

<ins> error: unexpected close delimiter: `}` --> $DIR/mismatched-delim-brace-empty-block.rs:5:1 | LL |   fn main() { |  ___________- LL | | LL | | } | |_- this block is empty, you might have not meant to close it LL |       let _ = (); LL |   } |   ^ unexpected close delimiter error: aborting due to previous error </ins>


Question:
It would be nice to get rustdoc to convert double-hyphen () (probably just when surrounded by spaces?) to a dash character () in doc-comments. People tend to use double-hyphen in code instead of the actual actual character, since it's easier to type on most keyboards. I reckon this could be done perfectly reliably.
Do you have an example of where it'd be useful? In such cases, I'm afraid of side-effects of unwanted replacements or maybe users' misunderstanding.
Well, it's just about nicer typography. See the rustc guide for example. What side effects do you imagine? The main one I can envisage is , but they should always be in backticks, I'd think... and you use a Markdown parser anyway, so I think it's okay.
So still doesn't sell much of a dream: ;)
Oh I know, the benefit is incremental... but the implementation cost is so low, and I don't see the downside. ;-)
I mean... don't we all like nice, propr typography?
Install a better font maybe? :stuckouttongue:
This is nothing to do with fonts... it's to do with vs. !
I'm assuming you mean converting a pair of hyphen-minus characters into an en dash like in TeX? rustdoc uses CommonMark and unless this was to that spec I don't think it's worth adding this feature. It's already possible to insert en dashes using for example.
Yes, I wrote it correctly in my title and the wrong way round in the comment oops. I think this is really orthogonal to Markdown to be honest... Sure, it's already possible, but no one is going to write in doc-comments, that's the problem. We might as well accept the convention and just aim for better typographical display.
I think this is simply incorrect: it's the em dash [—] that I'm trying to emulate when I use a double hyphen [--], not a single hyphen [-] (or an en dash [–] for that matter). Obviously "the actual hyphen character" is easy to type, since a double hyphen is literally just typing it twice. But assuming that was just terminology confusion, auto-converting a double hyphen to an em dash makes a lot of sense to me, and I feel like I've encountered this behavior in other tools before without complaint. Though it also seems reasonable to move this question to the CommonMark spec, since it probably ought to be done in all markdown-processing tools.
was was just me accidentally writing them the wrong way round (I had written it correctly earlier, oops!). en/em-dash is definitely not easier to type on most keyboards (which don't have it) and OSs. On Windows you need an Alt+code combination, and on macOS you need Alt + Shift + for the em-dash! Double-tapping the same key twice is a lot easier, I'm sure. you think the behaviour itself is useful. I agree it would probably make sense to become a part of CommonMark, but I don't think it needs to for us to implement it here. But I'll file an issue there anyway; good idea.
Ah, seems there's already an "optional extension" to the spec, but it has meaning en-dash and meaning em-dash, which is slightly awkward I think. (In practice, en-dash is encountered much less often, I find, since it used primarily for ranges, and the typographic difference from hyphen is less noticeable.)
This is my opinion as well.
See my above comment. It's an optional extension already part of the spec, according to that thread. :-)
Unless I'm mistaken rustdoc now uses pulldown-cmark which performs this transformation. Transformation is performed inconsistently - only in blocks it considers to be markdown. This makes generating documentation in markdown with extra html styling complicated enough to the point it's easier to generate just html. Either way this ticket seems to be completed.

<ins> // This test ensures that `--` (double-hyphen) is correctly converted into `–` (dash). #![crate_name = "foo"] // @has 'foo/index.html' '//*[@class="desc docblock-short"]' '–' // @has 'foo/struct.Bar.html' '//*[@class="docblock"]' '–' /// -- pub struct Bar; </ins>


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

use crate::hir::def_id::DefId; use crate::hir; use crate::ty::TyCtxt; <del> use syntax_pos::symbol::{sym, Symbol}; </del> <ins> use syntax_pos::symbol::Symbol; </ins> use crate::hir::map::blocks::FnLikeNode; use syntax::attr;


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

self.is_const_fn_raw(def_id) && match self.is_unstable_const_fn(def_id) { Some(feature_name) => { // has a `rustc_const_unstable` attribute, check whether the user enabled the <del> // corresponding feature gate, const_constructor is not a lib feature, so has // to be checked separately. </del> <ins> // corresponding feature gate. </ins> self.features() .declared_lib_features .iter() .any(|&(sym, _)| sym == feature_name) <del> || (feature_name == sym::const_constructor && self.features().const_constructor) </del> }, // functions without const stability are either stable user written // const fn or the user is using feature gates and we thus don't


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

/// Whether the `def_id` is an unstable const fn and what feature gate is necessary to enable it pub fn is_unstable_const_fn(self, def_id: DefId) -> Option<Symbol> { <del> if self.is_constructor(def_id) { Some(sym::const_constructor) } else if self.is_const_fn_raw(def_id) { </del> <ins> if self.is_const_fn_raw(def_id) { </ins> self.lookup_stability(def_id)?.const_stability } else { None


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

(accepted, macros_in_extern, "1.40.0", Some(49476), None), /// Allows future-proofing enums/structs with the `#[non_exhaustive]` attribute (RFC 2008). (accepted, non_exhaustive, "1.40.0", Some(44109), None), <ins> /// Allows calling constructor functions in `const fn`. (accepted, const_constructor, "1.40.0", Some(61456), None), </ins> // ------------------------------------------------------------------------- // feature-group-end: accepted features


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

/// Allows the user of associated type bounds. (active, associated_type_bounds, "1.34.0", Some(52662), None), <del> /// Allows calling constructor functions in `const fn`. (active, const_constructor, "1.37.0", Some(61456), None), </del> /// Allows `if/while p && let q = r && ...` chains. (active, let_chains, "1.37.0", Some(53667), None),


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

#![cfg_attr(const_fn, feature(const_fn))] <del> #![feature(const_constructor)] </del> // Ctor(..) is transformed to Ctor { 0: ... } in HAIR lowering, so directly // calling constructors doesn't require them to be const.


Question:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

<ins> // revisions: min_const_fn const_fn // run-pass #![cfg_attr(const_fn, feature(const_fn))] trait ConstDefault { const DEFAULT: Self; } #[derive(PartialEq)] enum E { V(i32), W(usize), } impl ConstDefault for E { const DEFAULT: Self = Self::V(23); } impl ConstDefault for Option<i32> { const DEFAULT: Self = Self::Some(23); } impl E { const NON_DEFAULT: Self = Self::W(12); const fn local_fn() -> Self { Self::V(23) } } const fn explicit_qpath() -> E { let _x = <Option<usize>>::Some(23); <E>::W(12) } fn main() { assert!(E::DEFAULT == E::local_fn()); assert!(Option::DEFAULT == Some(23)); assert!(E::NON_DEFAULT == explicit_qpath()); } </ins>