jiebi/CodeConvo huggingface dataset:
Change:
/// The trait itself acts as a builder for an associated /// `Searcher` type, which does the actual work of finding /// occurrences of the pattern in a string. <ins> /// /// Depending on the type of the pattern, the behaviour of methods like /// [`str::find`] and [`str::contains`] can change. The table below describes /// some of those behaviours. /// /// | Pattern type             | Match condition                           | /// |--------------------------|-------------------------------------------| /// | `&str`                   | is substring                              | /// | `char`                   | is contained in string                    | /// | `&[char]                 | any char in slice is contained in string  | /// | `F: FnMut(char) -> bool` | `F` returns `true` for a char in string   | /// | `&&str`                  | is substring                              | /// | `&String`                | is substring                              | /// /// # Examples /// ``` /// // &str /// assert_eq!("abaaa".find("ba"), Some(1)); /// assert_eq!("abaaa".find("bac"), None); /// /// // char /// assert_eq!("abaaa".find('a'), Some(0)); /// assert_eq!("abaaa".find('b'), Some(1)); /// assert_eq!("abaaa".find('c'), None); /// /// // &[char] /// assert_eq!("ab".find(&['b', 'a'][..]), Some(0)); /// assert_eq!("abaaa".find(&['a', 'z'][..]), Some(0)); /// assert_eq!("abaaa".find(&['c', 'd'][..]), None); /// /// // FnMut(char) -> bool /// assert_eq!("abcdef_z".find(|ch| ch > 'd' && ch < 'y'), Some(4)); /// assert_eq!("abcddd_z".find(|ch| ch > 'd' && ch < 'y'), None); /// ``` /// /// [`str::find`]: ../../../std/primitive.str.html#method.find /// [`str::contains`]: ../../../std/primitive.str.html#method.contains </ins> pub trait Pattern<'a>: Sized { /// Associated searcher for this pattern type Searcher: Searcher<'a>;

Discussion:
Correct me if I'm wrong, but I don't think it's possible to find out from the currently available online documentation if the following code returns true or false: Is searching for a slice of chars the same as searching for the string of the contatenation? Or is this a set match? There is no information on this in the following places:
If no one is working on it I would be happy to update this.
did you make any progress on this or is it alright for others to work on it?
I think it'd be best if the explanation is put on the page of (and not on the respective impls) so that it is easy to lookup in a central position. A small table and some examples should do such as the ones I've written . I don't know how to do a sanity check compile. Apparently I need to compile all of rustc(?!) to get the docs, which is not feasible for me. If anybody would like to send the PR, they can use my branch as a base. Maybe improve the wording as well.
Change:
<ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-83621-placeholder-static-in-extern.rs:4:15 | LL |     static x: _; |               ^ not allowed in type signatures error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </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. --<!-- 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
The ICE happens because the type placeholder error has been gone since 1.43.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
} if bounds.len() > 1 { <ins> let spans = bounds.iter().map(|b| { self.tcx().impl_or_trait_items(b.def_id()).iter() .find(|&&def_id| { match self.tcx().impl_or_trait_item(def_id) { ty::TypeTraitItem(ref item) => item.name.as_str() == assoc_name, _ => false } }) .and_then(|&def_id| self.tcx().map.as_local_node_id(def_id)) .and_then(|node_id| self.tcx().map.opt_span(node_id)) }); </ins> let mut err = struct_span_err!( self.tcx().sess, span, E0221, "ambiguous associated type `{}` in bounds of `{}`",

Discussion:
Currently, E0221 can give an error like: This isn't terribly helpful. Ideally, we'd like to show where these associated types that cause ambiguity are coming from: cc
I'd be up to mentor this. The message is reported by some code in , which has the job of converting the HIR representation of a type into the compiler's internal representation. The challenge here is that the HIR types have spans (because they are basically the things that the user wrote) whereas the internal representations do not. Right now, the routine in question, , only has access to a list of the representations in internal form (. To give better spans, we have to trace those spans in (so e.g. we want ). What this routine does is, given a type like , it selects what traits the associated type might have been defined in, and tries to pick one. The list is the list of traits that implements. So e.g. it might include something like , which would suggest that could be expanded to . But if there was another bound, say , that also defines an associated type , that'd be an amiguity. If you look at the callers, there aren't that many (3, I think). Two of those are for trait objects, I think, where the bounds come from the supertraits of the trait object. Probably we could give those the spans of the trait type itself, though we may want to get the spans out of the trait definition where the supertraits come from (but that could be in another crate). That last part is a bit tricky because we'd have to extend the . Let's assume we're not doing that for now, and we're willing to give a span referring to a trait when in fact the item lies in a supertrait where . The other is the more general case of a type parameter. I think the major piece of work then is to augment this routine in the trait: so that it returns a , where we would thread through the spans whence each bound was derived. Anyway, this is non-trivial, but seems to me to be achievable if anyone wants to dig in. If so, ping me (either on IRC, , or here) and I'll try to give more hints.

:)
I'll try, I need some time to look around
gettypeparameterbounds in callerbounds contains vec of Predicate w/o spans. May be is it easy only for error case in oneboundforassociatedtype get spans from astmap (hir::map) by DefId extracted from TypeTraitItems like traitdefinesassociatedtype_named do?
I've updated it But what do you think about trait from extern crate?
Change:
} }; <ins> let span = self.tcx.def_span(expr_def_id); </ins> let output_ty = match *ret_ty.kind() { ty::Infer(ty::TyVar(ret_vid)) => { self.obligations_for_self_ty(ret_vid).find_map(|obligation| {

Discussion:
I tried this code: It failed with a confusing error message. (error: concrete type differs from previous defining opaque type use, at the same location) I'm trying to minimize , and found the problem. compiles, but fails. Although not 100% sure, I think it's caused by the same problem as (regression caused by )
cc
I can work on this, and then I can test if it fixes the other issue too.
Change:
<ins> error[E0760]: `async fn` return type cannot contain a projection or `Self` that references lifetimes from a parent scope --> $DIR/issue-78600.rs:6:33 | LL |     async fn new(i: &'a i32) -> Result<Self, ()> { |                                 ^^^^^^^----^^^^^ |                                        | |                                        help: consider spelling out the type instead: `S<'a>` error: aborting due to previous error For more information about this error, try `rustc --explain E0760`. </ins>

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
use ast; use ast::{TokenTree, Ident}; use ast::{TtDelimited, TtSequence, TtToken}; <del> use codemap::{BytePos, mk_sp}; </del> <ins> use codemap::{BytePos, mk_sp, Span}; </ins> use codemap; use parse::lexer::*; //resolve bug? use parse::ParseSess;

Discussion:
I work on Windows 8.1 64-bit, rustc version: BTW, the same ICE occurred for my but it did not print backtrace with and I don't know why.
Change:
<ins> error[E0609]: no field `cap` on type `S` --> $DIR/private-field.rs:7:12 | LL |     dbg!(s.cap) |            ^^^ unknown field | = note: available fields are: `val` error: aborting due to previous error For more information about this error, try `rustc --explain E0609`. </ins>

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
Change:
displayPath = ""; href = rootPath + item.path.replace(/::/g, '/') + '/' + type + '.' + name + '.html'; <ins> } else if (type === "externcrate") { displayPath = ""; href = rootPath + name + '/index.html'; </ins> } else if (item.parent !== undefined) { var myparent = item.parent; var anchor = '#' + type + '.' + name;

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::util; use rustc_session::config::EntryFnType; <del> use rustc_span::{Span, DUMMY_SP}; </del> <ins> use rustc_span::{symbol::sym, Span, DUMMY_SP}; </ins> use rustc_target::spec::abi::Abi; use rustc_trait_selection::traits::error_reporting::InferCtxtExt as _; use rustc_trait_selection::traits::{

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
/// the case where an owned `Waker` is available. This method should be preferred to /// calling `waker.clone().wake()`. #[inline] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> pub fn wake_by_ref(&self) { // The actual wakeup call is delegated through a virtual function call // to the implementation which is defined by the executor.

Discussion:
The following code leaks memory: Miri error: The equivalent code with , so I think this is a bug. Cc
I guess this is not too surprising... has but has nothing like that.
Oh, that's may bad. I assumed that RawWaker handled ownership. I can push a PR today in the evening.
This leads to a miri-test-libstd failure every day, would be nice to get a fix soon. :)
Change:
<ins> // Regression test for issue #55825 // Tests that we don't emit a spurious warning in NLL mode #![feature(nll)] const fn no_dyn_trait_ret() -> &'static dyn std::fmt::Debug { &() } //~ ERROR const fn main() { } </ins>

Discussion:
Spawned off of (specificially in the project). Consider the following code: With AST-borrowck, you get (): With NLL (here using migration a la 2018 edition), you get (): I have not managed to replicate the above borrow-check error on code that does not exhibit some other error. And the problem goes away if you opt into (). So, this is really a very minor diagnostic issue.
Cc might be something in (min) const qualification?
TLDR: The issue with this is that we have a bunch of separate checks relating to const things, and most of these are spaghetti entangled into one. and I are working towards fixing that, but it's nontrivial to say the least. Details: We have the following checks that we need to run on MIR (which relate to const): minconstfn compliance constfn compliance promotion of runtime values to an anonymous static/constant const compliance (valid array length, const item initializer or enum discriminant) static compliance (valid static item initializer) no interior mutability checks no drop in const checks The current implementation has an early abort for const fns where if the feature gate is not active, we first run , and if that fails we don't run the entangled other 4 passes. If we ran the other passes in case of failure, you'd get a lot of error duplication. I don't think we have a tracking issue for the refactoring separating all these passes into distinct dataflow passes, but there's ongoing work.
This now produces the same output both with and without .
Change:
<del> // EMIT_MIR issue_78192.f.InstCombine.diff </del> <ins> // compile-flags: -Zmir-opt-level=1 -Zinline-mir </ins> pub fn f<T>(a: &T) -> *const T { let b: &*const T = &(a as *const T); *b

Discussion:
Previously: Now: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
<ins> // compile-flags: -Cpanic=unwind  --crate-type=lib // no-prefer-dynamic // edition:2021 #![feature(coroutines)] pub fn run<T>(a: T) { let _ = move || { drop(a); yield; }; } </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. -- <p<details</p</details<!-- 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</detailsBuild with
can reproduce
can you include a and (for example as a link to a project (+commit), or right here), to be able to reproduce this in the future?
Sorry, forgot to add those, I've attached them
does needs MCVE mean an example not relying on tokio?
yes
Ran a bisect. searched nightlies: from to regressed nightly: searched commit range: ... regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Spent some unforgettable time chopping down 80k lines of tokio code piece by piece, but it was worth it, I hope. Here's an MCVE: : :
Since this seems to be somehow caused by mir drop tracking, cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
fn main() { let args = env::args_os().skip(1).collect::<Vec<_>>(); <ins> let arg = |name| args.windows(2).find(|args| args[0] == name).and_then(|args| args[1].to_str()); </ins> // Detect whether or not we're a build script depending on whether --target // is passed (a bit janky...) <del> let target = args.windows(2).find(|w| &*w[0] == "--target").and_then(|w| w[1].to_str()); </del> <ins> let target = arg("--target"); </ins> let version = args.iter().find(|w| &**w == "-vV"); let verbose = match env::var("RUSTC_VERBOSE") {

Discussion:
On , with a provided component: errors with: I'll try and see if I can reproduce it with to test suggestion:
Couldn't reproduce it with an , tried with also Does it have to be cross compiled from a different host?
Not sure what is necessary to reproduce it. In any case if you open a PR with the likely fix, I can run a try build on CI which you can then locally install to see if it fixes the issue.
Change:
} } else if let Some(static_def_id) = constant.check_static_ptr(tcx) { let unnormalized_ty = tcx.type_of(static_def_id); <del> let locations = location.to_locations(); </del> let normalized_ty = self.cx.normalize(unnormalized_ty, locations); let literal_ty = constant.literal.ty().builtin_deref(true).unwrap().ty;

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 (): The current ( , regressed in the past week) output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --The desired result can be achieved by swapping the order of the two statements and . <!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim
Change:
} struct Foo; impl PointerFamily<u32> for Foo { type Pointer<usize> = Box<usize>; //~^ ERROR generic associated types are unstable

Discussion:
Compiling this code results in no output by . But exits with 101 and does not produce any artifacts. () The error happens with: , , and -
If I set breakpoints on - It hits the first two but not the third, seemingly pointing to returning an .
The silent exit is a regression. From godbolt, #### 1.23.0 exit code = 101 #### 1.24.0–1.25.0 exit code = 101 #### 1.26.0–1.28.0(beta) No message, exit code = 101 #### 1.29.0(nightly) No message, exit code = 1
cc -- it'd be good to find out why we stopped providing any output at all here
I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking .
It's not the parsing itself, it's that in 1.24 the feature was introduced:
do you think you see what the problem is?
Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.
The core issue is reported in However, the example here also demonstrates that clauses aren't being feature gated properly.
I've made to address the surface problem, which is that you can trigger this on stable, without declaring the feature. I thought it was better to fix that part of the problem straight away.
Narrowing it down a little more: is at this point when the clauses are defined, so something's going wrong before that point.
Change:
//         - This is because lang items are always callable from elsewhere. //   or //   2) We are not sure to be live or not <del> //     * Implementation of a trait method </del> <ins> //     * Implementations of traits and trait methods </ins> struct LifeSeeder<'k, 'tcx> { worklist: Vec<hir::HirId>, krate: &'k hir::Crate<'k>,

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 expected to see this happen: no warning is emitted. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'm not sure this needs to block , but it affects it, so marking as blocking for now.
claim
This is actually not an issue related to const generics :sweat_smile: It does not look at trait impls even if they are used as long as they don't overwrite the relevant method.