jiebi/CodeConvo huggingface dataset:
Change:
<ins> // edition:2018 // compile-flags:-Cincremental=tmp/issue-72442 use std::fs::File; use std::future::Future; use std::io::prelude::*; fn main() -> Result<(), Box<dyn std::error::Error>> { block_on(async { { let path = std::path::Path::new("."); let mut f = File::open(path.to_str())?; //~^ ERROR the trait bound let mut src = String::new(); f.read_to_string(&mut src)?; Ok(()) } }) } fn block_on<F>(f: F) -> F::Output where F: Future<Output = Result<(), Box<dyn std::error::Error>>>, { Ok(()) } </ins>

Discussion:
<!-- 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. --The rustc compiler panics for being unable to check the type of an object. In the example, it's shown in the form of returning an Option, and being unable to take Option as a parameter type. This would be the expected compilation error for that snippet of code, but instead of that, the compiler just panics. This error only occurs on asynchronous functions and in nightly. It also only happens when not compiling with --release, only in debug. <!-- 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</details
cc (likely due to - )
I can see why that could cause it. I've also seen that could be caused due to a similar issue. If it's the same issue, this issue should be kept as it provides a smaller example to reproduce and extra information in reproducing.
oh, sorry, my bad, investigating.
Kind of strange, this ice only triggered with , won't ice. here is a mcve: ICE: no-ICE:

<!-- 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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait MapLookup<Q> { type MapValue; } impl<K> MapLookup<K> for K { type MapValue = K; } trait Map: MapLookup<<Self as Map>::Key> { type Key; } impl<K> Map for K { type Key = K; } fn main() { let _ = &() as &Map<Key=u32,MapValue=u32>; //~^ ERROR the trait `Map` cannot be made into an object //~| NOTE the trait cannot use `Self` as a type parameter } </ins>

Discussion:
Attempting to compile the following with my  crate yields an ICE: Output from
Reduced:
I'm able to reproduce this exact same error on stable and nightly today using this 8 line example:
Change:
// dependent alignment #[no_mangle] pub fn small_array_alignment(x: &mut [i8; 4]) { <del> // CHECK: [[VAR:%[0-9]+]] = load [4 x i8]*, [4 x i8]** %x </del> <ins> // CHECK: [[VAR:%[0-9]+]] = load {{([4 x i8]*, )?}}[4 x i8]** %x </ins> // CHECK: [[VAR2:%[0-9]+]] = bitcast [4 x i8]* [[VAR]] to i32* // CHECK: store i32 %{{.*}}, i32* [[VAR2]], align 1 *x = [0; 4];

Discussion:
Hrm, yeah, the IR format changed from 3.6 to 3.7. In this case, it's just the extra result type in the instructions. Making that optional by changing to something like should help with that. If you still have a build using LLVM 3.6 around, it'd be great if you could create a patch for this. If not, let me know and I'll create one this evening.
I will give it a try. I am not planning to switch to 3.7 right now as there is no official release yet.
This is fixed.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> use cmp; </ins> use io; use libc::{c_int, c_void}; use mem;

Discussion:
In a few places in there are casts from to or for Windows APIs which causes breakage on 64-bit. Some examples I have found so far: () () (rust-lang-nursery/rand, ) There may be more.
Well I didn't find any more so I'll close this.
Change:
pub working_dir: PathBuf, pub lint_store: RefCell<lint::LintStore>, pub lints: RefCell<NodeMap<Vec<(lint::LintId, Span, String)>>>, <ins> /// Set of (LintId, span, message) tuples tracking lint (sub)diagnostics /// that have been set once, but should not be set again, in order to avoid /// redundantly verbose output (Issue #24690). pub one_time_diagnostics: RefCell<FnvHashSet<(lint::LintId, Span, String)>>, </ins> pub plugin_llvm_passes: RefCell<Vec<String>>, pub mir_passes: RefCell<mir_pass::Passes>, pub plugin_attributes: RefCell<Vec<(String, AttributeType)>>,

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in
Change:
} // Note that this test will deadlock if TLS destructors aren't run (this <del> // requires the destructor to be run to pass the test). macOS has a known bug // where dtors-in-dtors may cancel other destructors, so we just ignore this // test on macOS. </del> <ins> // requires the destructor to be run to pass the test). </ins> #[test] <del> #[cfg_attr(target_os = "macos", ignore)] </del> fn dtors_in_dtors_in_dtors() { struct S1(Sender<()>); thread_local!(static K1: UnsafeCell<Option<S1>> = UnsafeCell::new(None));

Discussion:
Moved from because the issue is not specific to . Repro: toolchain: rustc 1.33.0-nightly ( 2019-01-10) OSX 10.14 If thread is changed to access before exiting, then the ASAN error goes away. <details<summaryAddress Sanitizer Log</summary<p</p</details
Might be related to / caused by
Looking at the for and , it sure looks like UB to call during which lldb shows is happening in this example. This is worse than just not running tls destructors for the main thread. It is unsound AFAICT.
Thanks for debugging this I wonder if we can fix this on our end? We might be able to prevent new TLS slots from being initialized after a thread has exited perhaps?
I don't know how to reliably detect that a thread is exiting using the APIs that OSX provides (there could be a way). The logic in Apple's looks similar to what already exists in , except that handles destructor registering during thread exit properly AFAICT. Perhaps we could call into that . FWIW C++ has similar problems with "static local" thread locals when compiled by appleclang.
Makes sense yeah, perhaps as a fallback solution we could just fix this issue for Rust-spawned threads? For those we know exactly when they're exiting (or at least when user-written Rust code has ceased executing) and that may be enough too! Skipping may also be reasonable and we already do that on a number of other platforms too
visiting for T-compiler triage. Retagged as T-libs.
Filed an apple bug report.
Change:
<del> use errors::DiagnosticBuilder; </del> <ins> use errors::{Applicability, DiagnosticBuilder}; </ins> use syntax::ast::{self, *}; use syntax::source_map::Spanned; use syntax::ext::base::*; use syntax::ext::build::AstBuilder; use syntax::parse::token; <ins> use syntax::parse::parser::Parser; </ins> use syntax::print::pprust; use syntax::ptr::P; use syntax::symbol::Symbol;

Discussion:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.
Change:
let cid = key.value; let def_id = cid.instance.def.def_id(); let is_static = tcx.is_static(def_id); <del> let ecx = mk_eval_cx(tcx, tcx.def_span(key.value.instance.def_id()), key.param_env, is_static); </del> <ins> // This is just accessing an already computed constant, so no need to check alginment here. let ecx = mk_eval_cx( tcx, tcx.def_span(key.value.instance.def_id()), key.param_env, /*can_access_statics:*/ is_static, ); </ins> let mplace = ecx.raw_const_to_mplace(constant).expect( "can only fail if layout computation failed, 

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
def_id: DefId, tcx: TyCtxt<'tcx>, ) -> impl Iterator<Item = impl Iterator<Item = Ty<'tcx>> + Captures<'tcx>> { <del> let layout = tcx.generator_layout(def_id); </del> <ins> let layout = tcx.generator_layout(def_id).unwrap(); </ins> layout.variant_fields.iter().map(move |variant| { variant.iter().map(move |field| layout.field_tys[*field].subst(tcx, self.substs)) })

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:
Change:
assert(!at_exit_started && "registering at_exit function after exit"); if (at_exit_runner) { <del> assert(runner == at_exit_runner && "there can be only one at_exit_runner"); </del> <ins> // FIXME #2912 Would be very nice to assert this but we can't because // of the way coretest works (the test case ends up using its own // function) //assert(runner == at_exit_runner //       && "there can be only one at_exit_runner"); </ins> } at_exit_runner = runner;

Discussion:
As reported in the core test for atexit seems to be failing sometimes. It's failing because the atexit registration function expects to be passed the same pointer on each call but apparently isn't. I can imagine this could be because of the way coretest works, so coretest ends up using a different function than core. I can't though explain why this isn't showing up on the bots or in my tests.
is this still relevant? I'm not even sure which of the two at_exit tests this is referring to.
There appears to no longer be any at_exit function in the new runtime, except for a possible TLS destructor which will be removed in
Change:
/// Signifies that the compiler died with an explicit call to `.bug` /// or `.span_bug` rather than a failed assertion, etc. <del> #[derive(Copy, Clone, Debug)] </del> pub struct ExplicitBug; <del> impl fmt::Display for ExplicitBug { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { write!(f, "parser internal bug") } } impl error::Error for ExplicitBug {} </del> <ins> /// Signifies that the compiler died with an explicit call to `.delay_good_path_bug` /// rather than a failed assertion, etc. pub struct GoodPathBug; </ins> pub use diagnostic::{ AddToDiagnostic, DecorateLint, Diagnostic, DiagnosticArg, DiagnosticArgValue, DiagnosticId,

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
edition = "2018" [dependencies] <ins> colored = "2" </ins> diff = "0.1.10" <ins> unified-diff = "0.2.1" </ins> getopts = "0.2" tracing = "0.1" tracing-subscriber = { version = "0.2.13", default-features = false, features = ["fmt", "env-filter", "smallvec", "parking_lot", "ansi"] }

Discussion:
When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo<T> where T: Copy; struct Bar<T>(T) where T: Copy; struct Bleh<T, U>(T, U) where T: Copy, U: Sized; struct Baz<T> where T: Copy { field: T } fn main() {} </ins>

Discussion:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.
Change:
<ins> // Given an anon const `a`: `{ N }` and some anon const `b` which references the // first anon const: `{ [1; a] }`. `b` should not have any generics as it is not // a simple `N` argument nor is it a repeat expr count. // // On the other hand `b` *is* a repeat expr count and so it should inherit its // parents generics as part of the `const_evaluatable_unchecked` fcw (#76200). // // In this specific case however `b`'s parent should be `a` and so it should wind // up not having any generics after all. If `a` were to inherit its generics from // the enclosing item then the reference to `a` from `b` would contain generic // parameters not usable by `b` which would cause us to ICE. fn bar<const N: usize>() {} fn foo<const N: usize>() { bar::<{ [1; N] }>(); //~^ ERROR: generic parameters may not be used in const operations } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(effects) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [adtdestructor] computing impl for [checkwellformed] checking that is well-formed -- label +F-constmutrefs +F-consttrait_impl +F-effects
Regression in of
doesn't require any features actually, rip
Removed irrelevant errors:
Minimized: or
Change:
[rust-discord]: https://discord.gg/rust-lang [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html <del> [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ </del> <ins> [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ </ins> ## License

Discussion:
It seems that over the last 24 hours the link to the Rustdocs for the compiler has turned into a 404. At the bottom of the README there is a link to this url: which currently returns a Not Found response. I'm not sure if this is a problem caused by any recent changes to rustc or by the doc hosting itself. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The crate was renamed, the new link is Should be an easy fix, but I don't know where that page is located
Oh, the readme, duh
claim Seems easy enough for the first issue
Change:
use self::Destination::*; <del> use codemap::{self, COMMAND_LINE_SP, COMMAND_LINE_EXPN, Pos, Span}; </del> <ins> use codemap::{self, COMMAND_LINE_SP, COMMAND_LINE_EXPN, DUMMY_SP, Pos, Span}; </ins> use diagnostics; use errors::{Level, RenderSpan, DiagnosticBuilder};

Discussion:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")
Change:
} else { if matches!(def_kind, DefKind::AnonConst) && tcx.lazy_normalization() { let hir_id = tcx.hir().local_def_id_to_hir_id(def_id.expect_local()); <ins> let parent_def_id = tcx.hir().get_parent_item(hir_id); </ins> if tcx.hir().opt_const_param_default_param_hir_id(hir_id).is_some() { // In `generics_of` we set the generics' parent to be our parent's parent which means that // we lose out on the predicates of our actual parent if we dont return those predicates here.

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: This code should compile normally. Instead, this happened: In the function, T was already bounded by the trait which does have an associated item named . However, Rust complains that no associated item named was found for . <!-- 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. --:
I did some digging and this might be related to Mind taking a look?
A fix exists here at but we're waiting on 's pending RPIT refactor work to fix this. In the mean time, developers who need this feature can use the branch in . https://rust-
Change:
/// subt_vec_num(x: &[f64], y: f64) pub fn subt_vec_num() {} } <ins> pub mod long_list { //! bla //! //! * Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque et libero ut leo //!   interdum laoreet vitae a mi. Aliquam erat volutpat. Suspendisse volutpat non quam non //!   commodo. //! //!   Praesent enim neque, imperdiet sed nisl at, lobortis egestas augue. Sed vitae tristique //!   augue. Phasellus vel pretium lectus. //! * Praesent enim neque, imperdiet sed nisl at, lobortis egestas augue. Sed vitae tristique //!   augue. Phasellus vel pretium lectus. //! * Praesent enim neque, imperdiet sed nisl at, lobortis egestas augue. Sed vitae tristique //!   augue. Phasellus vel pretium lectus. //! //! Another list: //! //! * [`TryFromBytes`](#a) indicates that a type may safely be converted from certain byte //!   sequence (conditional on runtime checks) //! * [`FromZeros`](#a) indicates that a sequence of zero bytes represents a valid instance of //!   a type //! * [`FromBytes`](#a) indicates that a type may safely be converted from an arbitrary byte //!   sequence } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!