jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { &&[()][0]; println!("{:?}", &[(),()][1]); } </ins>

Discussion:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .
Change:
LL - fn bop<T: Bop + ?Sized>() { LL + fn bop<T: Bop>() { | <ins> help: consider relaxing the implicit `Sized` restriction | LL |     type Bar: Default + ?Sized |                       ++++++++ </ins> error: aborting due to 2 previous errors

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: A similar error message with an unsized generic type argument does mention the implicit bound. Unfortunately, it also doesn't explain the implicit bound up front in the "required by this bound" text. (It mentions it when suggesting to relax the implicit bound, but I think it would be better to mention it up front as well.) Both error messages could benefit from changing the "required by this bound" text to "required by an implicit bound". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-associated-items +A-traits +A-typesystem +D-papercut +D-terse
I'm working on a pull request for this issue. claim
Oh! Very sorry, if you spent too much time on this already, but I have done some work around this already in If you want, you can take over it and bring it to completion, there are some cases, like that still need to be addressed and I haven't yet figured out. Alternatively, if you can find a way to accomplish the same result without touching the and instead deal only with a new , that would be preferable to my approach.
I've pushed what I have so far to , sorry if it conflicts with stuff you've already done. If you'd like to take a look at it, that would be great. I'll take a look at what you have as well. There are some issues to be worked out with conflicting suggestions for associated types for vs the existing suggestion for adding an explicit to a trait's bounds, in test cases such as within a trait declaration.
Change:
<ins> // check-pass trait SomeTrait {} pub struct Exhibit { constant: usize, factory: fn(&usize) -> Box<dyn SomeTrait>, } pub const A_CONSTANT: &[Exhibit] = &[ Exhibit { constant: 1, factory: |_| unimplemented!(), }, Exhibit { constant: "Hello world".len(), factory: |_| unimplemented!(), }, ]; fn main() {} </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. --: Also happens on 1.48.0 and nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
On taking another look at the issues I found before filing this one, it looks like might be the same thing, as it has a similar stack trace. That code sample requires nightly, however, and this one does not. From a superficial examination (I know nothing about the compiler internals), both issues involve: multiple subexpressions (an array expression or a match) where the problem is sensitive to the number of them even if they're seemingly irrelevant a closure in one or more of the subexpressions calling a method on a literal in a constant context
This also reproduces the ICE:
Regression was too long ago to bisect to an individual commit, but the commit range is ....
Assigning as discussed as part of the and removing .
It looks like the ICE was introduced with / . The that triggers the ICE is at the end of . Issue , mentioned above by is triggered by a on the same but the error was already happening earlier in history. I observed it with the immediate parent commit .
Actually it looks like is the first commit with this issue
This is no longer ICE with the latest nightly, I think is the fix. Marking as .
Change:
match tcx.span_of_impl(parent_impl) { Ok(span) => { err.span_label(span, &"parent `impl` is here"); <del> err.note(&format!("to specialize, either the parent `impl` or `{}`  in the parent `impl` must be marked `default`", </del> <ins> err.note(&format!("to specialize, `{}` in the parent `impl` must be marked `default`", </ins> impl_item.name)); } Err(cname) => {

Discussion:
Because the itself cannot be marked , only the individual item.
Hi, I'm very new to rust and I'm trying to learn more about this language. I would like to make the change. Seems that I have to change the error text (e.g. ..., but the item of the parent impl is not marked ), Is it right? However searching about specialization documents I found this issue where seems that a will be possible. Am i missing something?
The text should suggest that the item could be , but not that the parent impl could be, because it can't. It might be in the future (as suggested by ) but that is not certain.
Hi , I'm seeing a bit more deep the specialization feature. I'm wondering if I can try to implement the . I have in mind to do what is described in the following quotes taken from the RFC For the moment, with this implementation, the must define all items of the trait (not a part of them) and, therefore, they will be all treated as default items. Would you accept a PR for this?
there is some debate at the moment about some of the details of specialisation. It would probably be best to open a thread on before starting to work on this.
PR was merged, so this can be closed now.
Change:
path = normalize_xpath(path) ret = False for e in tree.findall(path): <del> try: </del> <ins> if attr in e.attrib: </ins> value = e.attrib[attr] <del> except KeyError: continue </del> else: <del> ret = check_string(value, pat, regexp) if ret: break </del> <ins> continue ret = check_string(value, pat, regexp) if ret: break </ins> return ret

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.
Change:
} else if predicate_span.from_expansion() { // Don't try to extend the span if it comes from a macro expansion. where_lint_spans.push(predicate_span); <del> } else if i + 1 < num_predicates { </del> <ins> } else if i + 1 < num_where_predicates { </ins> // If all the bounds on a predicate were inferable and there are // further predicates, we want to eat the trailing comma. let next_predicate_span = hir_generics.predicates[i + 1].span();

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
<ins> fn foo() -> String { String::new() } fn main() { let string_arr = [foo(); 64]; //~ ERROR the trait bound `String: Copy` is not satisfied } </ins>

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
<ins> use std::fmt::Display; fn main() { test("hi", true); } fn test<T: Display>(t: T, recurse: bool) -> impl Display { let f = || { let i: u32 = test::<i32>(-1, false); //~^ ERROR mismatched types println!("{i}"); }; if recurse { f(); } t } </ins>

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
// aux-build:issue-13560-1.rs // aux-build:issue-13560-2.rs // aux-build:issue-13560-3.rs <ins> // ignore-pretty FIXME #19501 </ins> // ignore-stage1 // Regression test for issue #13560, the test itself is all in the dependent

Discussion:
Tracking issue for this failure:
It appears that the compiler is producing corrupt metadata somehow. I have modified the test to ignore and only link to , and I've found an interesting phenomena. When running the test via the rlib for -2 may end up containing two blobs of metadata. One blob of metadata ends in four 0x0a bytes (corrupted), and the other blob is the exact same but without these trailing bytes. The compilation of the -3 crate is the one that's failing, and it will deterministically fail depending on the metadata of the -2 crate. I do not currently know where the extra bytes come from, still trying to track that down...
Change:
<ins> // Copyright 2017 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. use Foo; use Foo1; fn main() {} </ins>

Discussion:
Sometimes it is very useful when rustc figures out that the faulty module use you just made is probably just a typo and directs you a potential match (thanks for that!). However it also directs you to potential matches which haven't been found either in certain cases, for example compiling currently (2016-11-28) yields with both stable and nightly the following output: While this is merely a suggestion displayed and shouldn't cause any harm at all maybe it might still be worth to check if what is suggested was actually found in the current scope. Or would that be too expensive (e.g. overhead in tracking what was already successfully imported and what not) and is thus left as is by design?
Is this easy to fix ? If so - maybe worth marking as so and mentioning on Rust Weekly ?
Yeah, I believe this can be fixed by replacing with .
I think I can take this, if it hasn't been worked on so far!
go for it
How can I assign myself?
Not sure if you can via github, due to permissions, but you can just start working on it :) There's a trace in the comments, anyone looking for more work would see them hopefully here in this issue.
Change:
let l_via_str = unsafe{&*(s as *const [u8])}; assert_eq!(&l, l_via_str); <ins> // ptr-ptr-cast (Length vtables, check length is preserved) let l: [[u8; 3]; 2] = [[3, 2, 6], [4, 5, 1]]; let p: *const [[u8; 3]] = &l; let p: &[[u8; 2]] = unsafe {&*(p as *const [[u8; 2]])}; assert_eq!(p, [[3, 2], [6, 4]]); </ins> // enum-cast assert_eq!(Simple::A as u8, 0); assert_eq!(Simple::B as u8, 1);

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
<ins> { "arch": "x86_64", "data-layout": "e-m:e-i64:16:32:64", "llvm-target": "x86_64-unknown-unknown-gnu", "target-pointer-width": "64" } </ins>

Discussion:
I'm new to Rust and I try to compile a project with a (I'm also new to that project and that project is not well organized.) when I use Makefile to make, the process of making executes and it reports it's a bug, so I'm here. I'm fresh here so if there is some information I don't provide, please tell me and I will try my best to provide it. Thank you! <!-- 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. --here I couldn't provide the example code since I don't really know the minimal set of code to be compiled the source code of the repo is in rustc should be in the nightly mode rust code is in the rust/sel4-rust/ in directory will execute in directory <!-- 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
Thank you for filing an issue! When I click that linked you posted, I get an error. Is it set that other people can view it?
Sorry, I have fixed the typo. Now the link should be right.(next time I will be more careful to check my issue)
The root of the issue is in the target definition file that the repository contains, however there are three other bugs that can be fixed in rustc: should not ICE when invalid external targets are being used; should report the actual target name/file in the error message, not the LLVM target name; target files are allowed to set the property.
The minimal target file to reproduce: with
( is a 404 )
Change:
[`riscv64-linux-android`](platform-support/android.md) |   |   | RISC-V 64-bit Android `s390x-unknown-linux-musl` |  |  | S390x Linux (kernel 3.2, MUSL) `sparc-unknown-linux-gnu` | ✓ |  | 32-bit SPARC Linux <ins> [`sparc-unknown-none-elf`](./platform-support/sparc-unknown-none-elf.md) | * | Bare 32-bit SPARC V7+ </ins> [`sparc64-unknown-netbsd`](platform-support/netbsd.md) | ✓ | ✓ | NetBSD/sparc64 [`sparc64-unknown-openbsd`](platform-support/openbsd.md) | ✓ | ✓ | OpenBSD/sparc64 `thumbv4t-none-eabi` | * |  | Thumb-mode Bare ARMv4T

Discussion:
lists sparc-unknown-none-elf as Tier 2, but it's Tier 3 as you don't build libcore for it. My bad - no idea how I managed to put it in the wrong table. It's not even alphabetically in the right place.
paging Sorry!
lmao whoops.
Change:
* @param {boolean} isAssocType */ function convertNameToId(elem, isAssocType) { <del> if (typeNameIdMap.has(elem.normalizedPathLast) && (isAssocType || !typeNameIdMap.get(elem.normalizedPathLast).assocOnly)) { elem.id = typeNameIdMap.get(elem.normalizedPathLast).id; </del> <ins> const loweredName = elem.pathLast.toLowerCase(); if (typeNameIdMap.has(loweredName) && (isAssocType || !typeNameIdMap.get(loweredName).assocOnly)) { elem.id = typeNameIdMap.get(loweredName).id; </ins> } else if (!parsedQuery.literalSearch) { let match = null; let matchDist = maxEditDistance + 1; let matchName = ""; for (const [name, {id, assocOnly}] of typeNameIdMap) { <del> const dist = editDistance(name, elem.normalizedPathLast, maxEditDistance); </del> <ins> const dist = Math.min( editDistance(name, loweredName, maxEditDistance), editDistance(name, elem.normalizedPathLast, maxEditDistance), ); </ins> if (dist <= matchDist && dist <= maxEditDistance && (isAssocType || !assocOnly)) { if (dist === matchDist && matchName > name) {

Discussion:
The "In Names" search tab is fine, but the "In Parameters" and "In Return Types" have the confusing note that ! label: +T-rustdoc +A-rustdoc-ui
Change:
<ins> // Ensure that `default async fn` will parse. // See issue #63716 for details. // check-pass // edition:2018 #![feature(specialization)] fn main() {} #[cfg(FALSE)] impl Foo for Bar { default async fn baz() {} } </ins>

Discussion:
The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.
Change:
pub const NONE: Option<CustomEq> = None; pub const SOME: Option<CustomEq> = Some(CustomEq); <ins> pub trait AssocConst { const NONE: Option<CustomEq> = None; const SOME: Option<CustomEq> = Some(CustomEq); } </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. --I don't have a reasonable sized reproducer yet. <!-- 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. --: Regression occurred ~between ..~ in () <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Updated the issue description with a complete backtrace that has full line info (435 frames deep!)
Update: I bisected this to () cc
it looks like this match needs to be updated somehow: Does this bug report contain enough information to understand the problem, or do you need an MCVE?
Could you reproduce but debug print the the scrutinee in the arm?
I'm surprised since we should return before calling for all other types. It must be one of the variants. That means we're using the of the associated const definition instead of the declaration. Maybe a defaulted associated const? I dunno.
Indeed, here's the source for the item being checked (specifically, ):
Ah okay. We should already be encoding the s for associated type defaults. If so, just adding an would resolve the issue. I think I can synthesize a test case from here though, so don't worry about reducing further. Thanks for the help!
No problem! Since I'd kicked this off already, here's the debug print:
Change:
<ins> // check-pass #![feature(generators, generator_trait)] use std::ops::Generator; pub fn example() -> impl Generator { || yield &1 } fn main() {} </ins>

Discussion:
I'm getting when trying to compile on rustc 1.29.0-nightly ( 2018-07-10) - . This seems to happen when I a reference type and don't specify the exact type in .
We don't generate an error message for the region here and panic instead. Here is the message that should be printed with a placeholder: Should be allowed for impl Trait? cc
Why are we capturing here?
There isn't any in the type. There's some which replaces regions with which is closure related. I'm not sure what is going on there, but perhaps generators should be treated the same? cc
Oh, all of that code is for exporting concrete types from inference results, which needs to "connect up" lifetimes inside the inferred concrete type with lifetime parameters.
I think the problem is that the of the generator ends up being , because nothing is constraining it to be anything else. I wonder why this isn't occurring with closures.
This doesn't occur with closures because regionck forces the return type of the closure to outlive the closure's call scope, which prevents from being inferred.
I think that the correct way to fix it would be to that goes in the wrong direction.
The requirement we want is that that "implicit" makes sense. That requires that the projections in that impl are alive as long as is alive (we don't consider that as a "well-formed" requirement, but the "projection outlives" rules assume that). That does not hold if regions in the projections can be inferred to - we need to be checking that.
I think that in closures, (from the fix to ) is serving that rule with lexical lifetimes - not sure what is checking that with NLL.
This can, in fact, be used as a soundness hole (assuming you can call ):
Note: the version above is fixed by NLL. need to check whether fix is tight.
any ideas on how to check whether the "fix is tight"? Otherwise perhaps this issue can be closed?