jiebi/CodeConvo huggingface dataset:
Change:
PatKind::Wild } Err(LitToConstError::Reported) => PatKind::Wild, <ins> Err(LitToConstError::TypeError) => bug!("lower_lit: had type error"), </ins> } } }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[feature(struct_variant)]; #[allow(dead_code)]; #[deny(raw_pointer_deriving)]; #[deriving(Clone)] struct Foo { x: *int //~ ERROR use of `#[deriving]` with a raw pointer } #[deriving(Clone)] struct Bar(*mut int); //~ ERROR use of `#[deriving]` with a raw pointer #[deriving(Clone)] enum Baz { A(*int), //~ ERROR use of `#[deriving]` with a raw pointer B { x: *mut int } //~ ERROR use of `#[deriving]` with a raw pointer } #[deriving(Clone)] struct Buzz { x: (*int, //~ ERROR use of `#[deriving]` with a raw pointer *uint) //~ ERROR use of `#[deriving]` with a raw pointer } fn main() {} </ins>

Discussion:
In the following, the does the wrong thing: it shallow copies the pointer when the semantics mean it should be making a new allocation and copying the data; there's no indication of this until runtime double-frees/segfaults. Some possible resolutions: do nothing: unsafe code is unsafe have lints for + unsafe pointers have completely disabled on unsafe pointers remove the trait impls for raw pointers
I favor a lint.
(I'm happy to mentor this.)
I'm interested in doing this. I'll find on IRC.
Change:
<ins> // Regression test for #62894, shouldn't crash. // error-pattern: this file contains an unclosed delimiter // error-pattern: expected one of `(`, `[`, or `{`, found keyword `fn` fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! fn main() {} </ins>

Discussion:
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report. I tried this code: jeremyBanks/0dmg using I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages! Instead, this happened: I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think. : : Backtrace:
If I use cargo doc I get a different stack trace:
The crash stopped occurring in my code when I fixed an invalid import: see jeremyBanks/0dmg
I'm pretty certain this is caused by being directly indexed without being checked here: But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards.
Makes sense. I'll try to pare it down to something useful.
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or doc test, but here's a reduced example ().
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust Result: If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet.
now that is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks!
I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using built from : Using : (Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P)
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a test.

If I get the test working behaving properly, would it be useful to send a PR to add my regression test, or is this too small of an issue to warrant one?
yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing.
Did a test ever get here?

Compiling this code results in: There is no backtrace. If I disable specialization feature, rustc reports an error: ` Rustc details:
This seems to compile as of the most recent nightly.
Good to hear that! Would it make sense to add this example to the test suite to prevent regressions in the future?
Change:
<ins> // Regression test for #62894, shouldn't crash. // error-pattern: this file contains an unclosed delimiter // error-pattern: expected one of `(`, `[`, or `{`, found keyword `fn` fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! fn main() {} </ins>

Discussion:
I wanted to test our handling of slices that are "too big" (bigger than the largest possible allocation), so I wrote: I expected an ICE or so, but I got a timeout. On nightly, here's what a stacktrace looks like: looks like the interning could do with a fast path for integer slices similar to what validation does? And maybe it could also check that the reference is dereferencable before walking it, that would avoid finding out later that we are going to produce an error anyway.
This now finishes in milliseconds with an error:

rustc crashes ungracefully when given the following input (found by ): I'm seeing this behavior on stable, beta, and nightly.
cc
Interesting: I'm not familiar with but that's where we are aborting:
cc
If I change the body of to this: then the compiler aborts how you would expect. I caught the panic in gdb (with ). It is coming from . Here's the stack trace: So it seems like this is a "legitimate" panic from the parser that the compiler would normally catch gracefully somewhere... except that assumes the closure it calls never panics and just aborts immediately if so. 's current implementation arose out of . any thoughts on how could let the panic pass through in a memory-safe manner? Or is that not possible?
I think there’s no magic trick here. Afaik the only safe way to do this is to mem::replace t with a dummy value, apply f, and swap the result back, but that requires that t has a dummy value. Does the code break if you add T: Default bound? Also, when suggesting that change I was 80% sure that it’s pure pedantry because, clearly, we don’t panic anywhere :) I am fascinated by how conspicuous and shallow such “benign” problems become in rust!
cc re:macros/ being ky.
Yes. Unfortunately, lots of the involved types lack a bound, and adding one doesn't make sense. wants the commit that introduced to be reverted anyway. Perhaps that's the best path forward, even though it'll be a perf hit. If I'd stuck with the original code that didn't handle panics it would have been a double-free without warning. One of those " is trickier than you might think" moments.
Or we just accept the current behaviour, because it's a benign abort on a very obscure case, and is being phased out anyway...
What's the plan post-? Benign to , but it will kill RLS or any other long lived tool. (Not that I disagree that we can live with this in the medium term.)
Just in case it's useful: here is a variation that causes (what I assume is) the same abort with only the macro:
I am unable to reproduce this crash on the latest releases. I was curious what fixed it, so I tried bisecting with nightlies.

The crash still happens on but no longer happens on . Unfortunately, it looks like nightlies are not available in between those two. In any case, as far as I'm concerned, this issue may be closed now.
Let's close this with a PR containing these repro cases as regression tests.
Change:
ty::RawPtr(..) => { // `#[structural_match]` ignores substructure of // `*const _`/`*mut _`, so skip super_visit_with <ins> // // (But still tell caller to continue search.) return false; } ty::FnDef(..) | ty::FnPtr(..) => { // types of formals and return in `fn(_) -> _` are also irrelevant // </ins> // (But still tell caller to continue search.) return false; }

Discussion:
A contrived example: This code will build on stable and beta, but not on nightly. It looks like it's related to possibly?
Compiler team triage: Definitely related to . Going to assign to for follow-up, although they are on leave until early September. It seems like this falls in a grey area: it was being accepted due to bugs in the existing code-base, however it is also a case that we likely could accept regardless of what rules we ultimately adopted. (Because the constant itself is a fn pointer.) is this regression affecting a real project?
I would say this is definitely a bug and the old behavior was correct: we're comparing function pointers so it shouldn't matter whether params derive or implement PartialEq, since no concrete parameter will be compared, but the functions themselves. Real projects being affected: I spotted the regression when updating my erlang VM implementation to latest nightly (and latest tokyo async/await): I define an Export as an enum that can either be a native function or an erlang function: Then in the instruction engine I cheat and override some of the exports to define them as a instruction (for example apply/2, apply/3 both need to modify the flow to jump to a different instruction): First I define a constant pointing to the function I want to override: Then I match on it and override: So the reason the code fails here is because is defined as , and has some custom code defined for . It's a bit of a hack, but this is more or less how erlang itself implements these specific instructions.
Reduced:
Changing to a raw pointer makes it compile successfully:
check-in from compiler triage: is back next week. A few weeks back, reported a real project affected by this regression (sorry!). As I wrote last week, from a lang-team perspective this falls into a grey zone, though I personally am inclined to try and accept the code, both for backwards compat reasons and because I don't think there's a compelling reason not to (though that depends on what complications result, I suppose). Overall, we need to settle our "constants in match patterns" story.
I'm going to leave this one nominated to bring it to felix's attention.
For the time being I've worked around the problem by taking the function pointers, casting them to usize then comparing that:
triage: P-high. Assigning to self.

Lets see if I can come up with something to fix this before this regression leaks out to stable.
(okay, after looking at the code, I think this should be pretty easy to fix and backport.)
Change:
} let header = match *self.kind { ItemKind::ForeignFunctionItem(_) => { <del> let abi = tcx.fn_sig(self.item_id.as_def_id().unwrap()).abi(); </del> <ins> let def_id = self.item_id.as_def_id().unwrap(); let abi = tcx.fn_sig(def_id).abi(); </ins> hir::FnHeader { unsafety: if abi == Abi::RustIntrinsic { intrinsic_operation_unsafety(tcx, self.item_id.as_def_id().unwrap())

Discussion:
and are both listed as const in 1.56 according to the "since" info on the right, but only the version lists in the actual signature. core: std:
I took this screenshot in : ! So it's fixed. Closing then.
I don't think this has been fixed yet. (note that this issue is about , not ) <img width="1009" alt="core" src="https://user-"
Oh you're right. Re-opening.
Change:
<ins> fn main() { let x = Some(()).iter().map(|()| 1).sum::<f32>(); //~^ ERROR a value of type `f32` cannot be made by summing an iterator over elements of type `{integer}` } </ins>

Discussion:
Regression from stable 1.66 / beta 1.67 -nightly 1.68 (haven't bisected). Stable/beta correctly produce an error, nightly ICEs. I've also confirmed the behavior on the latest commit to master (, at time of writing). (nightly — ICE) (beta — error as expected) (stable — error as expected) Setting produced the same output as above. I tried to dig into this, struggled to make sense of the typechecking code. I think the following is going on: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cargo-bisect-rustc seems to think this is caused by of which looks like the most plausible candidate since it touched type relation code which calls without handling infer vars :thinking: cc
Ugh i'll fix it claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
This is a bit weird, but I was able to come up with an alternative reduction (after hit it on - we use a pinned nightly so this is mostly a coincidence): I'm not sure why the inference variable vs generic param makes a difference like that, but I wasn't able to combine the two reductions together. Also, the ICE query stack confirms the / split between nightly versions, even in the combined example.
Change:
<ins> #![crate_type = "bin"] fn main() { my_lib::do_something(); } </ins>

Discussion:
I have a project that overrides the global allocator in , and recently noticed that I can no longer link the test binary for my project with recent beta/nightly compilers. points to which certainly looks relevant. I reproduced the error using a slightly modified example from the global allocator documentation: If I move the allocator definition from to , I no longer have a problem. Is that the right thing to do? If so, do I need to do anything else to make sure my tests use the desired allocator? I tried this code: I expected to see this happen: Instead, this happened: searched nightlies: from nightly-2023-05-25 to nightly-2023-06-16 regressed nightly: nightly-2023-05-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details modify labels: +regression-from-stable-to-beta -regression-untriaged
Adding the full linker error output here in case it's of interest.
I tried adding based on a brief look at the change that pointed to. It doesn't seem to make any difference, but that's why it's in my repro above.
I can reproduce this. and such are properly defined in the library rlib. It seems to be caused by the library order. Traditional linkers require symbols to have their uses in object files before their definition. So for circular dependencies and has to be used or libraries have to be mentioned multiple times. And indeed which doesn't have this restriction is entirely fine with this. I think registering a circular dependency between the defining crate of and liballoc (and every crate that depends on it) at would work. Edit: Reading the code it references closer, I think adding to would be enough to fix this. I can't work on this tomorrow, but unless someone else picks it up, I will work on this.
Finished some work early. fixes the issue.
thank you for the quick fix!
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
return; } let is_private = !cx.render_options.document_private <del> && !cx.cache.effective_visibilities.is_directly_public(cx.tcx, item_id); </del> <ins> && !cx.cache.effective_visibilities.is_directly_public(cx.tcx, did); </ins> if is_private { return; } <del> check_redundant_explicit_link(cx, item, hir_id, &doc); </del> <ins> let module_id = match cx.tcx.def_kind(did) { DefKind::Mod if item.inner_docs(cx.tcx) => did, _ => find_nearest_parent_module(cx.tcx, did).unwrap(), }; let Some(resolutions) = cx.tcx.resolutions(()).doc_link_resolutions.get(&module_id.expect_local()) else { // If there's no resolutions in this module, // then we skip resolution querying to // avoid from panicking. return; }; check_redundant_explicit_link(cx, item, hir_id, &doc, &resolutions); </ins> } fn check_redundant_explicit_link<'md>(

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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
} /// Attribute macro applied to a static to register it as a global allocator. <ins> /// /// See also [`std::alloc::GlobalAlloc`](../std/alloc/trait.GlobalAlloc.html). </ins> #[stable(feature = "global_allocator", since = "1.28.0")] #[allow_internal_unstable(rustc_attrs)] #[rustc_builtin_macro]

Discussion:
Seaching for in the docs only surfaces . The solution seems to link from to so people can read more. However I'm not sure how to create a link between these since they live in separate crates. What's the right way to go about this? edit: if someone wants to pick this up, please do. This is probably a "good first issue" once we figure out how to link between the two. ! -- this is how I eventually learned about ; ideally it'd be easier to find. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
These can't use intra-doc links, so you need to use relative links. I think would work.
Mentoring instructions: At add a link to .
Could I take this on as my first issue?
please do!
Feel free to use the command to assign the issue to yourself and show you're working on it
claim
yay; thanks for landing this
Change:
var OUTPUT_DATA = 1; var params = getQueryStringParams(); <ins> // Set the crate filter from saved storage, if the current page has the saved crate filter. // // If not, ignore the crate filter -- we want to support filtering for crates on sites like // doc.rust-lang.org where the crates may differ from page to page while on the same domain. var savedCrate = getCurrentValue("rustdoc-saved-filter-crate"); if (savedCrate !== null) { onEachLazy(document.getElementById("crate-search").getElementsByTagName("option"), function(e) { if (e.value === savedCrate) { document.getElementById("crate-search").value = e.value; return true; } }); } </ins> // Populate search bar with query string search term when provided, // but only if the input bar is empty. This avoid the obnoxious issue // where you start trying to do a search, and the index loads, and

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
use core::num::Float; #[test] <ins> fn from_str_issue7588() { let u : Option<u8> = u8::from_str_radix("1000", 10).ok(); assert_eq!(u, None); let s : Option<i16> = i16::from_str_radix("80000", 10).ok(); assert_eq!(s, None); } #[test] </ins> fn test_int_from_str_overflow() { let mut i8_val: i8 = 127; assert_eq!("127".parse::<i8>().ok(), Some(i8_val));

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .
Change:
<ins> // Check that we disallow GAT param defaults, even with `invalid_type_param_default` allowed #![allow(invalid_type_param_default)] trait Trait { type Assoc<T = u32>; //~^ defaults for type parameters are only allowed } impl Trait for () { type Assoc<T = u32> = u64; //~^ defaults for type parameters are only allowed } impl Trait for u32 { type Assoc<T = u32> = T; //~^ defaults for type parameters are only allowed } trait Other {} impl Other for u32 {} fn foo<T>() where T: Trait<Assoc = u32>, T::Assoc: Other { } fn main() { // errors foo::<()>(); // works foo::<u32>(); } </ins>

Discussion:
I tried this code: I expected to see this happen: It not work correctly as if you remove it shouts at you saying its unsupported and will be a hard error one day. Instead, this happened: defaults on GATs seem to function perfectly fine version from playground: cc this is probably should either be allowed or a hard error before stabilisation?
one issue is that we ignore defaults on the gat in impls
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
{ let tcx = closure_typer.tcx(); <del> debug!("normalize_param_env(value={})", value.repr(tcx)); </del> <ins> debug!("normalize_param_env(value={})", value.repr(tcx)); </ins> let mut selcx = &mut SelectionContext::new(infcx, closure_typer); let mut fulfill_cx = FulfillmentContext::new();

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',