jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for #39618, shouldn't crash. // FIXME(JohnTitor): Centril pointed out this looks suspicions, we should revisit here. // More context: https://github.com/rust-lang/rust/pull/69192#discussion_r379846796 // check-pass #![feature(specialization)] trait Foo { fn foo(&self); } trait Bar { fn bar(&self); } impl<T> Bar for T where T: Foo { fn bar(&self) {} } impl<T> Foo for T where T: Bar { fn foo(&self) {} } impl Foo for u64 {} 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:
//              return Try::from_error(From::from(err)),` let err_arm = { let err_ident = self.str_to_ident("err"); <del> let (err_local, err_local_nid) = self.pat_ident(e.span, err_ident); </del> <ins> let (err_local, err_local_nid) = self.pat_ident(try_span, err_ident); </ins> let from_expr = { let path = &["convert", "From", "from"]; let from = P(self.expr_std_path( <del> e.span, path, None, ThinVec::new())); let err_expr = self.expr_ident(e.span, err_ident, err_local_nid); </del> <ins> try_span, path, None, ThinVec::new())); let err_expr = self.expr_ident(try_span, err_ident, err_local_nid); </ins> <del> self.expr_call(e.span, from, hir_vec![err_expr]) </del> <ins> self.expr_call(try_span, from, hir_vec![err_expr]) </ins> }; let from_err_expr = self.wrap_in_try_constructor("from_error", from_expr, unstable_span);

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
flags.push((name, Some(value))); } <del> if let Some(true) = self_ty.ty_to_def_id().map(|def_id| def_id.is_local()) { </del> <ins> if let Some(true) = self_ty.ty_adt_def().map(|def| def.did.is_local()) { </ins> flags.push(("crate_local".to_string(), None)); }

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
use sys::handle::Handle; use sys_common::io::read_to_end_uninitialized; <del> pub struct NoClose(Option<Handle>); </del> pub enum Output { <del> Console(NoClose), Pipe(NoClose), </del> <ins> Console(c::HANDLE), Pipe(c::HANDLE), </ins> } pub struct Stdin { <del> handle: Output, </del> utf8: Mutex<io::Cursor<Vec<u8>>>, } <del> pub struct Stdout(Output); pub struct Stderr(Output); </del> <ins> pub struct Stdout; pub struct Stderr; </ins> pub fn get(handle: c::DWORD) -> io::Result<Output> { let handle = unsafe { c::GetStdHandle(handle) }; if handle == c::INVALID_HANDLE_VALUE { Err(io::Error::last_os_error()) } else if handle.is_null() { <del> Err(io::Error::new(io::ErrorKind::Other, "no stdio handle available for this process")) </del> <ins> Err(io::Error::from_raw_os_error(c::ERROR_INVALID_HANDLE as i32)) </ins> } else { <del> let ret = NoClose::new(handle); </del> let mut out = 0; match unsafe { c::GetConsoleMode(handle, &mut out) } { <del> 0 => Ok(Output::Pipe(ret)), _ => Ok(Output::Console(ret)), </del> <ins> 0 => Ok(Output::Pipe(handle)), _ => Ok(Output::Console(handle)), </ins> } } } <del> fn write(out: &Output, data: &[u8]) -> io::Result<usize> { let handle = match *out { Output::Console(ref c) => c.get().raw(), Output::Pipe(ref p) => return p.get().write(data), </del> <ins> fn write(handle: c::DWORD, data: &[u8]) -> io::Result<usize> { let handle = match try!(get(handle)) { Output::Console(c) => c, Output::Pipe(p) => { let handle = Handle::new(p); let ret = handle.write(data); handle.into_raw(); return ret } </ins> }; // As with stdin on windows, stdout often can't handle writes of large // sizes. For an example, see #14940. For this reason, don't try to // write the entire output buffer on windows.

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
<ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>

Discussion:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

() Errors:
/cc Related to but different from
This can be avoided by expressly allowing the type to be inferred:
: (as compared to )
After , this isn't fixed, but commenting out the call will cause it to error without ICEing (at the moment, it ICEs even without that line).
I configure struct by complicated const value and get this ICE. My code does something like this: Error: Note that type erase (as proposed does not help in my case. Until I found a way around this ICE.
Same error on:
I tried to port 's from to . Some of code is commented because of this bug and several other. I think this is good test for
Cannot reproduce the ICE with the above playground link.
It should be noted that while this no longer ICEs, this is because rustc no longer attempts to infer the type parameter causing it to fail to compile.

A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .
Change:
<ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>

Discussion:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.
Change:
UnreachablePub: UnreachablePub, ExplicitOutlivesRequirements: ExplicitOutlivesRequirements, InvalidValue: InvalidValue, <ins> DerefNullPtr: DerefNullPtr, </ins> ] ); };

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
<ins> error[E0004]: non-exhaustive patterns: type `Tait` is non-empty --> $DIR/unconstrained-due-to-bad-pattern.rs:8:15 | LL |         match empty_opaque() {} |               ^^^^^^^^^^^^^^ | = note: the matched value is of type `Tait` help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern as shown | LL ~         match empty_opaque() { LL +             _ => todo!(), LL +         } | error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </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 (): Somehow in the second case we think that is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions
I don't think that's it, same error if I put the match in a branch ():
In fact this doesn't need an empty type at all:
I think we're generating bogus MIR or THIR because of that empty match -- Are you sure the bug doesn't exist on the THIR/MIR building side, (hacked to dump the instead of )
Oh I'm sure of nothing I just assumed an unreachable in a branch would not affect anything else
So: If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. edit: that last sentence was a lie Let me see if I can cook up a quick fix.
Change:
_ => {} } <ins> debug!("note_type_err(diag={:?})", diag); </ins> let (expected_found, exp_found, is_simple_error) = match values { None => (None, None, false), Some(values) => {

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.
Change:
TargetOptions Options; Options.NoFramePointerElim = true; Options.EnableSegmentedStacks = EnableSegmentedStacks; <del> Options.FloatABIType = (Trip.getEnvironment() == Triple::GNUEABIHF) ? FloatABI::Hard : FloatABI::Default; </del> <ins> Options.FloatABIType = FloatABI::Default; </ins> Options.UseSoftFloat = UseSoftFloat; if (UseSoftFloat) { Options.FloatABIType = FloatABI::Soft;

Discussion:
Introduced by . This is because we now use to build but it defaults to soft float for all arm which is wrong for gnueabihf/eabihf. This is fixed in upstream llvm to choose the right float abi based on the target. This will no longer be an issue once we update llvm.
Change:
<ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-80779.rs:10:28 | LL | pub fn g(_: T<'static>) -> _ {} |                            ^ |                            | |                            not allowed in type signatures |                            help: replace with the correct return type: `()` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-80779.rs:5:29 | LL | pub fn f<'a>(val: T<'a>) -> _ { |                             ^ |                             | |                             not allowed in type signatures |                             help: replace with the correct return type: `()` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0121`. </ins>

Discussion:
<!-- 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: Same error on stable and beta. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this works for me on latest nightly. If you update your version of the compiler, does it work for you?
Oh oops, I was missing , sorry:
Slightly smaller: If you change to , it works, so I think this is while trying to infer .
glacier ""
This issue has been fixed by , marking as .

<!-- 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. --Hi, it appears that I've stumbled upon an internal compiler error. I'm sorry that I can't provide a minimal example, but I'm not on a level to understand what is going on (at least for now, heh :P). I'm just here, because the compiler told me to go here. I have, however, pushed a commit of my project in the state that yields the error: The error occurs when running or , for that matter. <!-- 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. --: Also happens on nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsI hope this helps. Please tell me, if there's more you need me to do.
reduced: `
modify labels: -E-needs-mcve
Assigning as and removing .
This ICEs since modify labels: +regression-from-stable-to-stable
This issue has been fixed by , marking as .
Change:
//! At present, however, we do run collection across all items in the //! crate as a kind of pass. This should eventually be factored away. <del> use crate::astconv::{AstConv, Bounds, SizedByDefault}; </del> <ins> use crate::astconv::{AstConv, SizedByDefault}; use crate::bounds::Bounds; </ins> use crate::check::intrinsic::intrinsic_operation_unsafety; use crate::constrained_generic_params as cgp; use crate::middle::resolve_lifetime as rl;

Discussion:
That file () has almost 3k LOC and just 3 lines of documentation on the file (methods and types are documented though). I'm entirely unsure how to process that file. I think splitting it up into submodules (e.g. start by extracting out all functions just handling error reporting into a separate module). Some of this work can be just mechanical splitting up, but some parts may require you to start understanding at least some of what's going on in the file in order to find a good module structure. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'll do it, although I am not familiar with the . At least the mechanical part is no problem. As to the model structure, I am going to dive into that issue so I can better think of a reasonable structure. If it is a problem that I am not familiar with the topic, I will back down, no worries.
That's awesome. Please wait until is merged though (you can subscribe to it so you see when it does get merged), because otherwise you'll just get loads of conflicts.
If you are unsure about the module structure, you can first post a design suggestion here if you want.
assign
You still working on this?
Not quite, my other PR is not yet through and I thought I wait for it. But if you want to do it, just take it. If not I'll be on it soon.
I would like to claim this, if nobody minds
assign It's all yours!
release-assignment
I'd like to work in this if is not on it anymore
generally it's fine if it's 3 months and there is no pr from the author. you can start working on it
Gotcha, thanks
claim
Change:
mkdir $(SRC) mkdir $(INCR) cp a.rs $(SRC)/main.rs <del> $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs </del> <ins> $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs --target $(TARGET) </ins> cp b.rs $(SRC)/main.rs <del> $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs </del> <ins> $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs --target $(TARGET) </ins>

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.