Question:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

<ins> fn main() { env!("EXISTING_ENV"); option_env!("EXISTING_OPT_ENV"); option_env!("NONEXISTENT_OPT_ENV"); option_env!("ESCAPEnESCAPE"); } </ins>


Question:
Sorry for the vague title. () <details<summaryRelevant errors:</summary</details<hrNote that this does not result in an ICE: Also works with shared references. <hr
Regression in – 1.44.0-nightly ( 2020-03-24) Commits:
This needs bisection ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I suspect based on .
Assigning and removing nomination. This was .
Oops, forgot to cc
I just tried to repro in our test suite and passes... This is on unmodified master from 03:00 this morning.
Oh interesting, this only reproduces with , probably because the function is then never really compiled because it's dead code. The following also ICEs
found a fix, not sure if that is too ad-hoc though.

_ => bug!(), }; <ins> let param_env = tcx.param_env(source.def_id()); </ins> for (local, decl) in body.local_decls.iter_enumerated() { // Ignore locals which are internal or not live if !live_locals.contains(local) || decl.internal { continue; } <ins> let decl_ty = tcx.normalize_erasing_regions(param_env, decl.ty); </ins> // Sanity check that typeck knows about the type of locals which are // live across a suspension point <del> if !allowed.contains(&decl.ty) && !allowed_upvars.contains(&decl.ty) { </del> <ins> if !allowed.contains(&decl_ty) && !allowed_upvars.contains(&decl_ty) { </ins> span_bug!( body.span, "Broken MIR: generator contains type {} in MIR,


Question:
Sorry for the vague title. () <details<summaryRelevant errors:</summary</details<hrNote that this does not result in an ICE: Also works with shared references. <hr
Regression in – 1.44.0-nightly ( 2020-03-24) Commits:
This needs bisection ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I suspect based on .
Assigning and removing nomination. This was .
Oops, forgot to cc
I just tried to repro in our test suite and passes... This is on unmodified master from 03:00 this morning.
Oh interesting, this only reproduces with , probably because the function is then never really compiled because it's dead code. The following also ICEs
found a fix, not sure if that is too ad-hoc though.

<ins> // check-pass // edition:2018 // compile-flags: --crate-type=lib pub async fn test() { const C: usize = 4; foo(&mut [0u8; C]).await; } async fn foo(_: &mut [u8]) {} </ins>


Question:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

format!("does not implement `{}`", trait_ref.print_only_trait_path()) }; <del> let mut explain_yield = |interior_span: Span, yield_span: Span, scope_span: Option<Span>| { let mut span = MultiSpan::from_span(yield_span); if let Ok(snippet) = source_map.span_to_snippet(interior_span) { span.push_span_label( yield_span, format!("{} occurs here, with `{}` maybe used later", await_or_yield, snippet), ); // If available, use the scope span to annotate the drop location. if let Some(scope_span) = scope_span { span.push_span_label( source_map.end_point(scope_span), format!("`{}` is later dropped here", snippet), ); </del> <ins> let mut explain_yield = |interior_span: Span, yield_span: Span, scope_span: Option<Span>| { let mut span = MultiSpan::from_span(yield_span); if let Ok(snippet) = source_map.span_to_snippet(interior_span) { // #70935: If snippet contains newlines, display "the value" instead // so that we do not emit complex diagnostics. let snippet = &format!("`{}`", snippet); let snippet = if snippet.contains('n') { "the value" } else { snippet }; // The multispan can be complex here, like: // note: future is not `Send` as this value is used across an await //   --> $DIR/issue-70935-complex-spans.rs:13:9 //    | // LL |            baz(|| async{ //    |  __________^___- //    | | _________| //    | || // LL | ||             foo(tx.clone()); // LL | ||         }).await; //    | ||         -      ^- value is later dropped here //    | ||_________|______| //    | |__________|      await occurs here, with value maybe used later //    |            has type `closure` which is not `Send` // // So, detect it and separate into some notes, like: // // note: future is not `Send` as this value is used across an await //   --> $DIR/issue-70935-complex-spans.rs:13:9 //    | // LL | /         baz(|| async{ // LL | |             foo(tx.clone()); // LL | |         }).await; //    | |________________^ first, await occurs here, with the value maybe used later... // note: the value is later dropped here //   --> $DIR/issue-70935-complex-spans.rs:15:17 //    | // LL |         }).await; //    |                 ^ // // If available, use the scope span to annotate the drop location. if let Some(scope_span) = scope_span { let scope_span = source_map.end_point(scope_span); let is_overlapped = yield_span.overlaps(scope_span) || yield_span.overlaps(interior_span); if is_overlapped { span.push_span_label( yield_span, format!( "first, {} occurs here, with {} maybe used later...", await_or_yield, snippet ), ); err.span_note( span, &format!( "{} {} as this value is used across {}", future_or_generator, trait_explanation, an_await_or_yield ), ); if source_map.is_multiline(interior_span) { err.span_note( scope_span, &format!("{} is later dropped here", snippet), ); err.span_note( interior_span, &format!( "this has type `{}` which {}", target_ty, trait_explanation ), ); } else { let mut span = MultiSpan::from_span(scope_span); span.push_span_label( interior_span, format!("has type `{}` which {}", target_ty, trait_explanation), ); err.span_note(span, &format!("{} is later dropped here", snippet)); } } else { span.push_span_label( yield_span, format!( "{} occurs here, with {} maybe used later", await_or_yield, snippet ), ); span.push_span_label( scope_span, format!("{} is later dropped here", snippet), ); span.push_span_label( interior_span, format!("has type `{}` which {}", target_ty, trait_explanation), ); err.span_note( span, &format!( "{} {} as this value is used across {}", future_or_generator, trait_explanation, an_await_or_yield ), ); } } else { span.push_span_label( yield_span, format!( "{} occurs here, with {} maybe used later", await_or_yield, snippet ), ); span.push_span_label( interior_span, format!("has type `{}` which {}", target_ty, trait_explanation), ); err.span_note( span, &format!( "{} {} as this value is used across {}", future_or_generator, trait_explanation, an_await_or_yield ), ); } </ins> } <del> } span.push_span_label( interior_span, format!("has type `{}` which {}", target_ty, trait_explanation), ); err.span_note( span, &format!( "{} {} as this value is used across {}", future_or_generator, trait_explanation, an_await_or_yield ), ); }; </del> <ins> }; </ins> match interior_or_upvar_span { GeneratorInteriorOrUpvar::Interior(interior_span) => { if let Some((scope_span, yield_span, expr, from_awaited_ty)) = interior_extra_info {


Question:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

<ins> // edition:2018 // #70935: Check if we do not emit snippet // with newlines which lead complex diagnostics. use std::future::Future; async fn baz<T>(_c: impl FnMut() -> T) where T: Future<Output=()> { } fn foo(tx: std::sync::mpsc::Sender<i32>) -> impl Future + Send { //~^ ERROR: future cannot be sent between threads safely async move { baz(|| async{ foo(tx.clone()); }).await; } } fn bar(_s: impl Future + Send) { } fn main() { let (tx, _rx) = std::sync::mpsc::channel(); bar(foo(tx)); } </ins>


Question:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

<ins> error: future cannot be sent between threads safely --> $DIR/issue-70935-complex-spans.rs:10:45 | LL | fn foo(tx: std::sync::mpsc::Sender<i32>) -> impl Future + Send { |                                             ^^^^^^^^^^^^^^^^^^ future created by async block is not `Send` | = help: the trait `Sync` is not implemented for `Sender<i32>` note: future is not `Send` as this value is used across an await --> $DIR/issue-70935-complex-spans.rs:13:9 | LL | /         baz(|| async{ LL | |             foo(tx.clone()); LL | |         }).await; | |________________^ first, await occurs here, with the value maybe used later... note: the value is later dropped here --> $DIR/issue-70935-complex-spans.rs:15:17 | LL |         }).await; |                 ^ note: this has type `[closure@$DIR/issue-70935-complex-spans.rs:13:13: 15:10]` which is not `Send` --> $DIR/issue-70935-complex-spans.rs:13:13 | LL |           baz(|| async{ |  _____________^ LL | |             foo(tx.clone()); LL | |         }).await; | |_________^ error: aborting due to previous error </ins>


Question:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

--> $DIR/issue-65436-raw-ptr-not-send.rs:14:9 | LL |         bar(Foo(std::ptr::null())).await; <del> |         ^^^^^^^^----------------^^^^^^^^- `std::ptr::null()` is later dropped here |         |       | |         |       has type `*const u8` which is not `Send` |         await occurs here, with `std::ptr::null()` maybe used later </del> <ins> |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ first, await occurs here, with `std::ptr::null()` maybe used later... note: `std::ptr::null()` is later dropped here --> $DIR/issue-65436-raw-ptr-not-send.rs:14:41 | LL |         bar(Foo(std::ptr::null())).await; |                 ----------------        ^ |                 | |                 has type `*const u8` which is not `Send` </ins> help: consider moving this into a `let` binding to create a shorter lived borrow --> $DIR/issue-65436-raw-ptr-not-send.rs:14:13 |


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

} if let Some(non_sm_ty) = structural { <del> let adt_def = match non_sm_ty { traits::NonStructuralMatchTy::Adt(adt_def) => adt_def, </del> <ins> let msg = match non_sm_ty { traits::NonStructuralMatchTy::Adt(adt_def) => { let path = self.tcx().def_path_str(adt_def.did); format!( "to use a constant of type `{}` in a pattern,  `{}` must be annotated with `#[derive(PartialEq, Eq)]`", path, path, ) } traits::NonStructuralMatchTy::Dynamic => { format!("trait objects cannot be used in patterns") } </ins> traits::NonStructuralMatchTy::Param => { bug!("use of constant whose type is a parameter inside a pattern") } }; <del> let path = self.tcx().def_path_str(adt_def.did); let make_msg = || -> String { format!( "to use a constant of type `{}` in a pattern,  `{}` must be annotated with `#[derive(PartialEq, Eq)]`", path, path, ) }; </del> // double-check there even *is* a semantic `PartialEq` to dispatch to. //


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

if !ty_is_partial_eq { // span_fatal avoids ICE from resolution of non-existent method (rare case). <del> self.tcx().sess.span_fatal(self.span, &make_msg()); </del> <ins> self.tcx().sess.span_fatal(self.span, &msg); </ins> } else if mir_structural_match_violation { self.tcx().struct_span_lint_hir( lint::builtin::INDIRECT_STRUCTURAL_MATCH, self.id, self.span, <del> |lint| lint.build(&make_msg()).emit(), </del> <ins> |lint| lint.build(&msg).emit(), </ins> ); } else { debug!(


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

pub enum NonStructuralMatchTy<'tcx> { Adt(&'tcx AdtDef), Param, <ins> Dynamic, </ins> } /// This method traverses the structure of `ty`, trying to find an


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

self.found = Some(NonStructuralMatchTy::Param); return true; // Stop visiting. } <ins> ty::Dynamic(..) => { self.found = Some(NonStructuralMatchTy::Dynamic); return true; // Stop visiting. } </ins> ty::RawPtr(..) => { // structural-match ignores substructure of // `*const _`/`*mut _`, so skip `super_visit_with`.


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait A {} struct B; impl A for B {} fn test<const T: &'static dyn A>() { //~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used unimplemented!() } fn main() { test::<{ &B }>(); } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-63322-forbid-dyn.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error[E0741]: `&'static (dyn A + 'static)` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter --> $DIR/issue-63322-forbid-dyn.rs:8:18 | LL | fn test<const T: &'static dyn A>() { |                  ^^^^^^^^^^^^^^ `&'static (dyn A + 'static)` doesn't derive both `PartialEq` and `Eq` error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0741`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

<ins> const F: &'static dyn Send = &7u32; fn main() { let a: &dyn Send = &7u32; match a { F => panic!(), //~^ ERROR trait objects cannot be used in patterns _ => {} } } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.

<ins> error: trait objects cannot be used in patterns --> $DIR/issue-70972-dyn-trait.rs:6:9 | LL |         F => panic!(), |         ^ error: aborting due to previous error </ins>


Question:
These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.

See the specification for the [GitHub Tables extension][tables] for more details on the exact syntax supported.  ### Task lists Task lists can be used as a checklist of items that have been completed. Example: ```md - [x] Complete task - [ ] IncComplete task ``` This will render as

<input type="checkbox">

<input type="checkbox" checked>

 See the specification for the [task list extension] for more details.  [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/


Question:
These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.

[`std::env`]: https://doc.rust-lang.org/stable/std/env/index.html#functions [strikethrough]: https://github.github.com/gfm/#strikethrough-extension- [tables]: https://github.github.com/gfm/#tables-extension- <ins> [task list extension]: https://github.github.com/gfm/#task-list-items-extension- </ins>


Question:
These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.

/// Options for rendering Markdown in the main body of documentation. pub(crate) fn opts() -> Options { <del> Options::ENABLE_TABLES | Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH </del> <ins> Options::ENABLE_TABLES | Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH | Options::ENABLE_TASKLISTS </ins> } /// A subset of [`opts()`] used for rendering summaries.


Question:
These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.

<ins> // ignore-tidy-linelength // FIXME: this doesn't test as much as I'd like; ideally it would have these query too: // has task_lists/index.html '//li/input[@type="checkbox" and disabled]/following-sibling::text()' 'a' // has task_lists/index.html '//li/input[@type="checkbox"]/following-sibling::text()' 'b' // Unfortunately that requires LXML, because the built-in xml module doesn't support all of xpath. // @has task_lists/index.html '//ul/li/input[@type="checkbox"]' '' // @has task_lists/index.html '//ul/li/input[@disabled]' '' // @has task_lists/index.html '//ul/li' 'a' // @has task_lists/index.html '//ul/li' 'b' //! This tests 'task list' support, a common markdown extension. //! - [ ] a //! - [x] b </ins>


Question:
In this example: rustc throws a warning: Removing the parentheses as the message directs causes errors: It seems the warning is wrong, unless this is expected to compile <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This also happens on nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this may apply to any binary op where the left-hand side is an expression that can be a statement without a semicolon, per: For example, adding with block expressions also reports unused parens: but removing those gets an error: As a workaround, it doesn't trigger if the operands are wrapped separately: or
claim

); fn is_expr_delims_necessary(inner: &ast::Expr, followed_by_block: bool) -> bool { <del> followed_by_block && match inner.kind { ExprKind::Ret(_) | ExprKind::Break(..) => true, _ => parser::contains_exterior_struct_lit(&inner), </del> <ins> // Prevent false-positives in cases like `fn x() -> u8 { ({ 0 } + 1) }` let lhs_needs_parens = { let mut innermost = inner; loop { if let ExprKind::Binary(_, lhs, _rhs) = &innermost.kind { innermost = lhs; if !rustc_ast::util::classify::expr_requires_semi_to_be_stmt(innermost) { break true; } } else { break false; } </ins> } <ins> }; lhs_needs_parens || (followed_by_block && match inner.kind { ExprKind::Ret(_) | ExprKind::Break(..) => true, _ => parser::contains_exterior_struct_lit(&inner), }) </ins> } fn emit_unused_delims_expr(


Question:
In this example: rustc throws a warning: Removing the parentheses as the message directs causes errors: It seems the warning is wrong, unless this is expected to compile <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This also happens on nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this may apply to any binary op where the left-hand side is an expression that can be a statement without a semicolon, per: For example, adding with block expressions also reports unused parens: but removing those gets an error: As a workaround, it doesn't trigger if the operands are wrapped separately: or
claim

<ins> // check-pass // Make sure unused parens lint doesn't emit a false positive. // See https://github.com/rust-lang/rust/issues/71290 for details. #![deny(unused_parens)] fn x() -> u8 { ({ 0 }) + 1 } fn y() -> u8 { ({ 0 } + 1) } pub fn foo(a: bool, b: bool) -> u8 { (if a { 1 } else { 0 } + if b { 1 } else { 0 }) } pub fn bar() -> u8 { // Make sure nested expressions are handled correctly as well ({ 0 } + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9) } fn main() {} </ins>


Question:
Notice the extra one column of indentation in front of the pipes. I presume this is unintentional because almost any other error is still printed without such extra indentation; for example: The relevant commit range is Mentioning because looks like it touches error messages vaguely along the same lines. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Could you show the output of ? The only thing I can think of is that there's a span that isn't being displayed.
<details<summary<codecargo +nightly-2020-04-20 check --message-format=json | jq</code</summarycompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}ncompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}n </details
I'm pretty sure it's happening because of this It is weird because that file should be accessible to in all environments now. I think we can get away with some well placed in a few places.
It maybe be nice if someone can find where this regressed ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as .
cargo bisect-rustc indicates that the regression is @ / PR cc
claim

return 0; }; <ins> let will_be_emitted = |span: Span| { !span.is_dummy() && { let file = sm.lookup_source_file(span.hi()); sm.ensure_source_file_source_present(file) } }; </ins> let mut max = 0; for primary_span in msp.primary_spans() { <del> if !primary_span.is_dummy() { </del> <ins> if will_be_emitted(*primary_span) { </ins> let hi = sm.lookup_char_pos(primary_span.hi()); max = (hi.line).max(max); } } if !self.short_message { for span_label in msp.span_labels() { <del> if !span_label.span.is_dummy() { </del> <ins> if will_be_emitted(span_label.span) { </ins> let hi = sm.lookup_char_pos(span_label.span.hi()); max = (hi.line).max(max); }


Question:
Notice the extra one column of indentation in front of the pipes. I presume this is unintentional because almost any other error is still printed without such extra indentation; for example: The relevant commit range is Mentioning because looks like it touches error messages vaguely along the same lines. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Could you show the output of ? The only thing I can think of is that there's a span that isn't being displayed.
<details<summary<codecargo +nightly-2020-04-20 check --message-format=json | jq</code</summarycompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}ncompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}n </details
I'm pretty sure it's happening because of this It is weird because that file should be accessible to in all environments now. I think we can get away with some well placed in a few places.
It maybe be nice if someone can find where this regressed ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as .
cargo bisect-rustc indicates that the regression is @ / PR cc
claim

<ins> // compile-flags: -Z simulate-remapped-rust-src-base=/rustc/xyz -Z ui-testing=no // only-x86_64-unknown-linux-gnu //---^ Limiting target as the above unstable flags don't play well on some environment. struct MyError; impl std::error::Error for MyError {} //~^ ERROR: `MyError` doesn't implement `std::fmt::Display` //~| ERROR: `MyError` doesn't implement `Debug` fn main() {} </ins>


Question:
Notice the extra one column of indentation in front of the pipes. I presume this is unintentional because almost any other error is still printed without such extra indentation; for example: The relevant commit range is Mentioning because looks like it touches error messages vaguely along the same lines. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Could you show the output of ? The only thing I can think of is that there's a span that isn't being displayed.
<details<summary<codecargo +nightly-2020-04-20 check --message-format=json | jq</code</summarycompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}ncompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}n </details
I'm pretty sure it's happening because of this It is weird because that file should be accessible to in all environments now. I think we can get away with some well placed in a few places.
It maybe be nice if someone can find where this regressed ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as .
cargo bisect-rustc indicates that the regression is @ / PR cc
claim

<ins> error[E0277]: `MyError` doesn't implement `std::fmt::Display` --> $DIR/issue-71363.rs:6:6 | 6 | impl std::error::Error for MyError {} |      ^^^^^^^^^^^^^^^^^ `MyError` cannot be formatted with the default formatter | = help: the trait `std::fmt::Display` is not implemented for `MyError` = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead note: required by a bound in `std::error::Error` error[E0277]: `MyError` doesn't implement `Debug` --> $DIR/issue-71363.rs:6:6 | 6 | impl std::error::Error for MyError {} |      ^^^^^^^^^^^^^^^^^ `MyError` cannot be formatted using `{:?}` | = help: the trait `Debug` is not implemented for `MyError` = note: add `#[derive(Debug)]` to `MyError` or manually `impl Debug for MyError` note: required by a bound in `std::error::Error` help: consider annotating `MyError` with `#[derive(Debug)]` | 5 | #[derive(Debug)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(*const usize); type PassArg = (); unsafe extern "C" fn pass(args: PassArg) { println!("Hello, world!"); } impl Test { pub fn call_me<Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args)>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden self.0 = Self::trampiline::<Args, IDX, FN> as _ } unsafe extern "C" fn trampiline< Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args), //~^ ERROR: using function pointers as const generic parameters is forbidden >( args: Args, ) { FN(args) } } fn main() { let x = Test(); x.call_me::<PassArg, 30, pass>() } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:13:61 | LL |     pub fn call_me<Args: Sized, const IDX: usize, const FN: unsafe extern "C" fn(Args)>(&self) { |                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71381.rs:21:19 | LL |         const FN: unsafe extern "C" fn(Args), |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71611.rs:4:21 | LL | fn func<A, const F: fn(inner: A)>(outer: A) { |                     ^^^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-72352.rs:6:42 | LL | unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { |                                          ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

}; } <del> let binding = if let Some(module) = module { self.resolve_ident_in_module( module, ident, ns, parent_scope, record_used, path_span, ) } else if ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS) { let scopes = ScopeSet::All(ns, opt_ns.is_none()); self.early_resolve_ident_in_lexical_scope( ident, scopes, parent_scope, record_used, record_used, path_span, ) } else { let record_used_id = if record_used { crate_lint.node_id().or(Some(CRATE_NODE_ID)) } else { None }; match self.resolve_ident_in_lexical_scope( ident, ns, parent_scope, record_used_id, path_span, &ribs.unwrap()[ns], ) { // we found a locally-imported or available item/module Some(LexicalScopeBinding::Item(binding)) => Ok(binding), // we found a local variable or type param Some(LexicalScopeBinding::Res(res)) if opt_ns == Some(TypeNS) || opt_ns == Some(ValueNS) => { record_segment_res(self, res); return PathResult::NonModule(PartialRes::with_unresolved_segments( res, path.len() - 1, )); </del> <ins> enum FindBindingResult<'a> { Binding(Result<&'a NameBinding<'a>, Determinacy>), PathResult(PathResult<'a>), } let find_binding_in_ns = |this: &mut Self, ns| { let binding = if let Some(module) = module { this.resolve_ident_in_module( module, ident, ns, parent_scope, record_used, path_span, ) } else if ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS) { let scopes = ScopeSet::All(ns, opt_ns.is_none()); this.early_resolve_ident_in_lexical_scope( ident, scopes, parent_scope, record_used, record_used, path_span, ) } else { let record_used_id = if record_used { crate_lint.node_id().or(Some(CRATE_NODE_ID)) } else { None }; match this.resolve_ident_in_lexical_scope( ident, ns, parent_scope, record_used_id, path_span, &ribs.unwrap()[ns], ) { // we found a locally-imported or available item/module Some(LexicalScopeBinding::Item(binding)) => Ok(binding), // we found a local variable or type param Some(LexicalScopeBinding::Res(res)) if opt_ns == Some(TypeNS) || opt_ns == Some(ValueNS) => { record_segment_res(this, res); return FindBindingResult::PathResult(PathResult::NonModule( PartialRes::with_unresolved_segments(res, path.len() - 1), )); } _ => Err(Determinacy::determined(record_used)), </ins> } <del> _ => Err(Determinacy::determined(record_used)), } </del> <ins> }; FindBindingResult::Binding(binding) }; let binding = match find_binding_in_ns(self, ns) { FindBindingResult::PathResult(x) => return x, FindBindingResult::Binding(binding) => binding, </ins> }; match binding { Ok(binding) => { if i == 1 {


Question:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

} else if i == 0 { (format!("use of undeclared type or module `{}`", ident), None) } else { <del> (format!("could not find `{}` in `{}`", ident, path[i - 1].ident), None) </del> <ins> let mut msg = format!("could not find `{}` in `{}`", ident, path[i - 1].ident); if ns == TypeNS || ns == ValueNS { let ns_to_try = if ns == TypeNS { ValueNS } else { TypeNS }; if let FindBindingResult::Binding(Ok(binding)) = find_binding_in_ns(self, ns_to_try) { let mut found = |what| { msg = format!( "expected {}, found {} `{}` in `{}`", ns.descr(), what, ident, path[i - 1].ident ) }; if binding.module().is_some() { found("module") } else { match binding.res() { def::Res::<NodeId>::Def(kind, id) => found(kind.descr(id)), _ => found(ns_to_try.descr()), } } }; } (msg, None) </ins> }; return PathResult::Failed { span: ident.span,


Question:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

<ins> use std::sync::mpsc; fn main() { let (tx, rx) = mpsc::channel::new(1); //~^ ERROR expected type, found function `channel` in `mpsc` } </ins>


Question:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

<ins> error[E0433]: failed to resolve: expected type, found function `channel` in `mpsc` --> $DIR/issue-71406.rs:4:26 | LL |     let (tx, rx) = mpsc::channel::new(1); |                          ^^^^^^^ expected type, found function `channel` in `mpsc` error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>


Question:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

&b.item_def_id, ))) } else { <del> let ty = relation.relate(&a.ty, &b.ty)?; let substs = relation.relate(&a.substs, &b.substs)?; </del> <ins> let ty = relation.relate_with_variance(ty::Invariant, &a.ty, &b.ty)?; let substs = relation.relate_with_variance(ty::Invariant, &a.substs, &b.substs)?; </ins> Ok(ty::ExistentialProjection { item_def_id: a.item_def_id, substs, ty }) } }


Question:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

LL |     let _ = Box::new(|x| (x as u8)): Box<dyn Fn(i32) -> _>; |             ^^^^^^^^^^^^^^^^^^^^^^^ expected trait object `dyn std::ops::Fn`, found closure | <del> = note: expected struct `std::boxed::Box<dyn std::ops::Fn(i32) -> _>` </del> <ins> = note: expected struct `std::boxed::Box<dyn std::ops::Fn(i32) -> u8>` </ins> found struct `std::boxed::Box<[closure@$DIR/coerce-expect-unsized-ascribed.rs:26:22: 26:35]>` error: aborting due to 14 previous errors


Question:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

<del> error[E0277]: the size for values of type `dyn std::iter::Iterator<Item = &mut u8>` cannot be known at compilation time </del> <ins> error[E0277]: the size for values of type `dyn std::iter::Iterator<Item = &'a mut u8>` cannot be known at compilation time </ins> --> $DIR/issue-20605.rs:2:17 | LL |     for item in *things { *item = 0 } |                 ^^^^^^^ doesn't have a size known at compile-time | <del> = help: the trait `std::marker::Sized` is not implemented for `dyn std::iter::Iterator<Item = &mut u8>` </del> <ins> = help: the trait `std::marker::Sized` is not implemented for `dyn std::iter::Iterator<Item = &'a mut u8>` </ins> = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait> = note: required by `std::iter::IntoIterator::into_iter`


Question:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

<ins> error: lifetime may not live long enough --> $DIR/variance-associated-types2.rs:13:12 | LL | fn take<'a>(_: &'a u32) { |         -- lifetime `'a` defined here LL |     let _: Box<dyn Foo<Bar = &'a u32>> = make(); |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^ type annotation requires that `'a` must outlive `'static` | = help: consider replacing `'a` with `'static` error: aborting due to previous error </ins>


Question:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

<ins> // Test that dyn Foo<Bar = T> is invariant with respect to T. // Failure to enforce invariance here can be weaponized, see #71550 for details. trait Foo { type Bar; } fn make() -> Box<dyn Foo<Bar = &'static u32>> { panic!() } fn take<'a>(_: &'a u32) { let _: Box<dyn Foo<Bar = &'a u32>> = make(); //~^ ERROR mismatched types [E0308] } fn main() {} </ins>


Question:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

<ins> error[E0308]: mismatched types --> $DIR/variance-associated-types2.rs:13:42 | LL |     let _: Box<dyn Foo<Bar = &'a u32>> = make(); |                                          ^^^^^^ lifetime mismatch | = note: expected trait object `dyn Foo<Bar = &'a u32>` found trait object `dyn Foo<Bar = &'static u32>` note: the lifetime `'a` as defined on the function body at 12:9... --> $DIR/variance-associated-types2.rs:12:9 | LL | fn take<'a>(_: &'a u32) { |         ^^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
despite it being usable in . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hi there. Are you still working on this? :)
couldn't find the time to look into this deeper, sorry. Feel free to pick it up.
The target features for a particular architecture are taken from llvm in line 341. The seems to be a rust-specific target feature that is not present in llvm feature table, I think its the only one right now. I have made a basic naive pr which just prints it out since I'm hoping to get feedback for improving it

printf("Available features for this target:n"); for (auto &Feature : FeatTable) printf("    %-*s - %s.n", MaxFeatLen, Feature.Key, Feature.Desc); <ins> printf("nRust-specific features:n"); printf("    %-*s - %s.n", MaxFeatLen, "crt-static", "Enables libraries with C Run-time Libraries(CRT) to be statically linked" ); </ins> printf("n"); printf("Use +feature to enable a feature, or -feature to disable it.n"


Question:
The specified method, EventsPoll::new looks like: might be related with the static mut?, but haven't tried to replicate it on a smaller example, will report back if i do so
cc Would be good to find out if this was caused by , and to find an MCVE, so: ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Imma try to bisect this, it's as good an opportunity as any to learn about it!
here's a minimal example that is self-contained and shows the issue:
Bisect shows the ICE was introduced between the nightlies of the 26th (no ICE) and the 27th (ICE is present). My pc is trying to find the particular commit still, but if that takes too long (like if it has to compile (I have no idea, this is my first time bisecting)) I'll leave it to people with beefier computers :3 That said, I think you can at least rest assured-ish because our PR was merged on the 29th (according to Github).
Minimized a bit further:
Wait, bisect just finished. :laughing: searched nightlies: from nightly-2020-04-26 to nightly-2020-04-28 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit: source code: Please give the steps for how to build your repository (platform, system dependencies, etc.) <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
(working on the stack trace)
Use the  tool, which fetches the artifacts generated by when testing a PR. Your CPU will be way happier :D
Yaaas that's precisely what I used. It's sooooo goooooood :sparkles:
(I haven't been able to minimize since my last comment, so I think it is now minimal)
Awesome. I'll bisect again with that one. For now, I've the full backtrace taken from today's nightly to the bisect report. Do you know how I can compile using a specific rustc's commit? (I just did and used , which used today's nightly.
Now we know which PR regressed (). It's a rollup of multiple PRs, so we'll need to guess which one is the culprit using the power of deduction :D Here I'm pretty sure this has been caused by , cc
Kay, I'll leave it to Oli then. He knows way more than I do about static initialization soundness :D also, it's (apparently) his PR. I've done one last test: did bisect with your minimal counterexample, which ICE'd on the same commit. I've edited the bisection report to have your and its backtrace :3
I cannot tell if you are being facetious here, but there is the option of bisecting over the individual PR's in the rollup itself, e.g. via directly on a local rust checkout. It is unfortunate that we don't have a way to do that mechanically within itself (which would be a huge undertaking)
From some local testing, I can confirm that reverting from fixes the ICE. cc
yeah I think posted PR which essentially reverted by moving the check elsewhere (so that we still get the fix that was trying to land). Its just waiting review; I looked at it briefly but I'm not an expert on that code so I'm going to wait for to look at it.
Right, that sentence was unclear, sorry about that. I just wrote something quickly, to tell that they didn't need to bisect every PR in the rollup, that would have been a waste of time.
it's completely fine! I got your friendly tone when you posted it. The was very helpful in that regard :rainbow: :slightlysmilingface:

// We can still be zero-sized in this branch, in which case we have to // return `None`. <del> if size.bytes() == 0 { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. The caller is likely // to short-circuit on `None`, so we trigger the access here to // make sure it happens. self.get_raw(ptr.alloc_id)?; None } else { Some(ptr) } </del> <ins> if size.bytes() == 0 { None } else { Some(ptr) } </ins> } }) }


Question:
The specified method, EventsPoll::new looks like: might be related with the static mut?, but haven't tried to replicate it on a smaller example, will report back if i do so
cc Would be good to find out if this was caused by , and to find an MCVE, so: ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Imma try to bisect this, it's as good an opportunity as any to learn about it!
here's a minimal example that is self-contained and shows the issue:
Bisect shows the ICE was introduced between the nightlies of the 26th (no ICE) and the 27th (ICE is present). My pc is trying to find the particular commit still, but if that takes too long (like if it has to compile (I have no idea, this is my first time bisecting)) I'll leave it to people with beefier computers :3 That said, I think you can at least rest assured-ish because our PR was merged on the 29th (according to Github).
Minimized a bit further:
Wait, bisect just finished. :laughing: searched nightlies: from nightly-2020-04-26 to nightly-2020-04-28 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit: source code: Please give the steps for how to build your repository (platform, system dependencies, etc.) <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
(working on the stack trace)
Use the  tool, which fetches the artifacts generated by when testing a PR. Your CPU will be way happier :D
Yaaas that's precisely what I used. It's sooooo goooooood :sparkles:
(I haven't been able to minimize since my last comment, so I think it is now minimal)
Awesome. I'll bisect again with that one. For now, I've the full backtrace taken from today's nightly to the bisect report. Do you know how I can compile using a specific rustc's commit? (I just did and used , which used today's nightly.
Now we know which PR regressed (). It's a rollup of multiple PRs, so we'll need to guess which one is the culprit using the power of deduction :D Here I'm pretty sure this has been caused by , cc
Kay, I'll leave it to Oli then. He knows way more than I do about static initialization soundness :D also, it's (apparently) his PR. I've done one last test: did bisect with your minimal counterexample, which ICE'd on the same commit. I've edited the bisection report to have your and its backtrace :3
I cannot tell if you are being facetious here, but there is the option of bisecting over the individual PR's in the rollup itself, e.g. via directly on a local rust checkout. It is unfortunate that we don't have a way to do that mechanically within itself (which would be a huge undertaking)
From some local testing, I can confirm that reverting from fixes the ICE. cc
yeah I think posted PR which essentially reverted by moving the check elsewhere (so that we still get the fix that was trying to land). Its just waiting review; I looked at it briefly but I'm not an expert on that code so I'm going to wait for to look at it.
Right, that sentence was unclear, sorry about that. I just wrote something quickly, to tell that they didn't need to bisect every PR in the rollup, that would have been a waste of time.
it's completely fine! I got your friendly tone when you posted it. The was very helpful in that regard :rainbow: :slightlysmilingface:

{ Some(ptr) => ptr, None => { <ins> if let Scalar::Ptr(ptr) = mplace.ptr { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. self.memory.get_raw(ptr.alloc_id)?; } </ins> return Ok(Some(ImmTy { // zero-sized type imm: Scalar::zst().into(),


Question:
The specified method, EventsPoll::new looks like: might be related with the static mut?, but haven't tried to replicate it on a smaller example, will report back if i do so
cc Would be good to find out if this was caused by , and to find an MCVE, so: ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Imma try to bisect this, it's as good an opportunity as any to learn about it!
here's a minimal example that is self-contained and shows the issue:
Bisect shows the ICE was introduced between the nightlies of the 26th (no ICE) and the 27th (ICE is present). My pc is trying to find the particular commit still, but if that takes too long (like if it has to compile (I have no idea, this is my first time bisecting)) I'll leave it to people with beefier computers :3 That said, I think you can at least rest assured-ish because our PR was merged on the 29th (according to Github).
Minimized a bit further:
Wait, bisect just finished. :laughing: searched nightlies: from nightly-2020-04-26 to nightly-2020-04-28 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit: source code: Please give the steps for how to build your repository (platform, system dependencies, etc.) <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
(working on the stack trace)
Use the  tool, which fetches the artifacts generated by when testing a PR. Your CPU will be way happier :D
Yaaas that's precisely what I used. It's sooooo goooooood :sparkles:
(I haven't been able to minimize since my last comment, so I think it is now minimal)
Awesome. I'll bisect again with that one. For now, I've the full backtrace taken from today's nightly to the bisect report. Do you know how I can compile using a specific rustc's commit? (I just did and used , which used today's nightly.
Now we know which PR regressed (). It's a rollup of multiple PRs, so we'll need to guess which one is the culprit using the power of deduction :D Here I'm pretty sure this has been caused by , cc
Kay, I'll leave it to Oli then. He knows way more than I do about static initialization soundness :D also, it's (apparently) his PR. I've done one last test: did bisect with your minimal counterexample, which ICE'd on the same commit. I've edited the bisection report to have your and its backtrace :3
I cannot tell if you are being facetious here, but there is the option of bisecting over the individual PR's in the rollup itself, e.g. via directly on a local rust checkout. It is unfortunate that we don't have a way to do that mechanically within itself (which would be a huge undertaking)
From some local testing, I can confirm that reverting from fixes the ICE. cc
yeah I think posted PR which essentially reverted by moving the check elsewhere (so that we still get the fix that was trying to land). Its just waiting review; I looked at it briefly but I'm not an expert on that code so I'm going to wait for to look at it.
Right, that sentence was unclear, sorry about that. I just wrote something quickly, to tell that they didn't need to bisect every PR in the rollup, that would have been a waste of time.
it's completely fine! I got your friendly tone when you posted it. The was very helpful in that regard :rainbow: :slightlysmilingface:

<ins> // check-pass // This is a regression test for ICEs from // https://github.com/rust-lang/rust/issues/71612 // and // https://github.com/rust-lang/rust/issues/71709 #[derive(Copy, Clone)] pub struct Glfw; static mut GLFW: Option<Glfw> = None; pub fn new() -> Glfw { unsafe { if let Some(glfw) = GLFW { return glfw; } else { todo!() } }; } extern "C" { static _dispatch_queue_attr_concurrent: [u8; 0]; } static DISPATCH_QUEUE_CONCURRENT: &'static [u8; 0] = unsafe { &_dispatch_queue_attr_concurrent }; fn main() { *DISPATCH_QUEUE_CONCURRENT; new(); } </ins>


Question:
The first impl block with a constant is not collapsible like the second impl block with a function. !
As far as I can tell, this is the desired behaviour (not to hide associated impl constant). So unless I'm missing something, there is nothing to fix here? cc
Why are they not hidden? It felt surprising to me, as they are part of the impl block. Also because if an impl block contains both constants and methods, both the constants and the methods are hidden when the impl block is collapsed (and this I expected).
For example  contains constants, and it is collapsible, with both the constants and the methods hidden on collapse.
It seems weird to me as well but I wasn't the one enforcing it and I don't remember the reason. Let's wait to hear from first.
It seems odd to me that they're not treated equivalently.

if (!next) { return; } <del> if (next.getElementsByClassName("method").length > 0 && hasClass(e, "impl")) { </del> <ins> if (hasClass(e, "impl") && (next.getElementsByClassName("method").length > 0 || next.getElementsByClassName("associatedconstant").length > 0)) { </ins> insertAfter(toggle.cloneNode(true), e.childNodes[e.childNodes.length - 1]); } };


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Command: This code is from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)

use crate::middle::cstore::{ExternCrate, ExternCrateSource}; <del> use crate::mir::interpret::{sign_extend, truncate, AllocId, ConstValue, Pointer, Scalar}; </del> <ins> use crate::mir::interpret::{ sign_extend, truncate, AllocId, ConstValue, GlobalAlloc, Pointer, Scalar, }; </ins> use crate::ty::layout::IntegerExt; use crate::ty::subst::{GenericArg, GenericArgKind, Subst}; use crate::ty::{self, DefIdTree, ParamConst, Ty, TyCtxt, TypeFoldable};


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Command: This code is from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)

}, _, ), <del> ) => { let byte_str = self .tcx() .global_alloc(ptr.alloc_id) .unwrap_memory() .get_bytes(&self.tcx(), ptr, Size::from_bytes(*data)) .unwrap(); p!(pretty_print_byte_str(byte_str)); } </del> <ins> ) => match self.tcx().get_global_alloc(ptr.alloc_id) { Some(GlobalAlloc::Memory(alloc)) => { if let Ok(byte_str) = alloc.get_bytes(&self.tcx(), ptr, Size::from_bytes(*data)) { p!(pretty_print_byte_str(byte_str)) } else { p!(write("<too short allocation>")) } } // FIXME: for statics and functions, we could in principle print more detail. Some(GlobalAlloc::Static(def_id)) => p!(write("<static({:?})>", def_id)), Some(GlobalAlloc::Function(_)) => p!(write("<function>")), None => p!(write("<dangling pointer>")), }, </ins> // Bool (Scalar::Raw { data: 0, .. }, ty::Bool) => p!(write("false")), (Scalar::Raw { data: 1, .. }, ty::Bool) => p!(write("true")),


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Command: This code is from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)

)?; } (Scalar::Ptr(ptr), ty::FnPtr(_)) => { <ins> // FIXME: this can ICE when the ptr is dangling or points to a non-function. // We should probably have a helper method to share code with the "Byte strings" // printing above (which also has to handle pointers to all sorts of things). </ins> let instance = self.tcx().global_alloc(ptr.alloc_id).unwrap_fn(); self = self.typed_value( |this| this.print_value_path(instance.def_id(), instance.substs),