jiebi/CodeConvo huggingface dataset:
Change:
ty::Predicate::Projection(ref data) => { let project_obligation = obligation.with(data.clone()); match project::poly_project_and_unify_type(selcx, &project_obligation) { <ins> Ok(None) => { pending_obligation.stalled_on = trait_ref_type_vars(selcx, data.to_poly_trait_ref()); Ok(None) } </ins> Ok(v) => Ok(v), Err(e) => Err(CodeProjectionError(e)) }

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
hir_id = tcx.hir().get_parent_item(hir_id); } // Syntactically, we are allowed to define the concrete type if: <del> hir_id == scope </del> <ins> let res = hir_id == scope; trace!( "may_define_existential_type(def={:?}, opaque_node={:?}) = {}", tcx.hir().get(hir_id), tcx.hir().get(opaque_hir_id), res ); res </ins> }

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
<ins> // Allows to track issue #75492: // https://github.com/rust-lang/rust/issues/75492 use std::iter; fn main() { format!("A number: {}". iter::once(42).next().unwrap()); //~^ ERROR expected token: `,` // Other kind of types are also checked: format!("A number: {}" / iter::once(42).next().unwrap()); //~^ ERROR expected token: `,` format!("A number: {}"; iter::once(42).next().unwrap()); //~^ ERROR expected token: `,` // Note: this character is an COMBINING COMMA BELOW unicode char format!("A number: {}" ̦ iter::once(42).next().unwrap()); //~^ ERROR expected token: `,` //~^^ ERROR unknown start of token: u{326} } </ins>

Discussion:
says: ... which isn't exactly where the was expected. () Another variation is this code: which gives this result: ()
Hello, I am a quite new contributor, and I'd like to tackle this issue. Do you think that is possible? I have looked a bit at the code, and I think this mostly comes from the [] function, more precisely, [this condition][cond] can be tweaked. Is that correct? []: [cond]:
Turns out I was terribly wrong. The problem is that the following snippet: Can be rewritten as: And that the [] function looks for an expression as the first argument ([corresponding code][expression], [code example][snippet]). Consequently, is the said expression, which explain why the error is raised on the first . Now that I know where the error comes from. I think the best way to fix this issue is to check if this expression can be a format string, perhaps with the [] function. I am still unsure about the quality of the emitted error, but at least it would have the correct span. []: [expression]: [snippet]: []:
Change:
tcx.mk_adt(def, substs) } ItemKind::OpaqueTy(OpaqueTy { origin: hir::OpaqueTyOrigin::TyAlias, .. }) => { <del> find_opaque_ty_constraints(tcx, def_id) </del> <ins> find_opaque_ty_constraints_for_tait(tcx, def_id) </ins> } // Opaque types desugared from `impl Trait`. ItemKind::OpaqueTy(OpaqueTy { origin: hir::OpaqueTyOrigin::FnReturn(owner) | hir::OpaqueTyOrigin::AsyncFn(owner), .. }) => { <del> let concrete_ty = tcx .mir_borrowck(owner) .concrete_opaque_types .get(&def_id) .copied() .map(|concrete| concrete.ty) .unwrap_or_else(|| { let table = tcx.typeck(owner); if let Some(_) = table.tainted_by_errors { // Some error in the // owner fn prevented us from populating // the `concrete_opaque_types` table. tcx.ty_error() } else { table.concrete_opaque_types.get(&def_id).copied().unwrap_or_else(|| { // We failed to resolve the opaque type or it // resolves to itself. We interpret this as the // no values of the hidden type ever being constructed, // so we can just make the hidden type be `!`. // For backwards compatibility reasons, we fall back to // `()` until we the diverging default is changed. Some(tcx.mk_diverging_default()) }).expect("RPIT always have a hidden type from typeck") } }); debug!("concrete_ty = {:?}", concrete_ty); concrete_ty </del> <ins> find_opaque_ty_constraints_for_rpit(tcx, def_id, owner) </ins> } ItemKind::Trait(..) | ItemKind::TraitAlias(..)

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:
<ins> // aux-build:ctor-stability.rs // check-pass extern crate ctor_stability; fn main() { let _ = ctor_stability::Foo::A; } </ins>

Discussion:
Example: . This was fixed by adding stability attributes (), but the general problem remains that was able to land. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Found the bug. PR incoming. claim

As of current nightly rustc 1.65.0-nightly ( 2022-08-10): : Mentioning erstwhile tracking issue Mentioning in connection with .
"encountered unmarked API" &mdash; maybe it's that there is no #[stable] attribute on the enum variants, like there is in other stable enums? I'd have expected that to be caught during the libstd build, so we should fix whatever was supposed to catch it, not just add the attributes.
Indeed, I didn't realize that enum variants also needed stable attributes.
Change:
a: &'tcx ty::Const<'tcx>, b: &'tcx ty::Const<'tcx>, ) -> RelateResult<'tcx, &'tcx ty::Const<'tcx>> { <del> debug!("{}.consts({:?}, {:?})", self.tag(), a, b); if a == b { return Ok(a); } </del> self.fields.infcx.super_combine_consts(self, a, b) }

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
} let mut new_abis = Vec::new(); <del> loop { </del> <ins> while !p.eat(&token::CloseDelim(Delimiter::Parenthesis)) { </ins> match p.parse_str_lit() { Ok(str_lit) => { new_abis.push((str_lit.symbol_unescaped, str_lit.span)); } Err(opt_lit) => { <del> // If the non-string literal is a closing paren then it's the end of the list and is fine if p.eat(&token::CloseDelim(Delimiter::Parenthesis)) { break; } </del> let span = opt_lit.map_or(p.token.span, |lit| lit.span); let mut err = p.sess.span_diagnostic.struct_span_err(span, "expected string literal");

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim
Change:
fn x() {} // not object safe, shouldn't be reported } <del> // This ideally should not have any upcasting cost, // but currently does due to a bug </del> <ins> // This does not have any upcasting cost, // because both `Send` and `Sync` are traits // with no methods </ins> trait D: Send + Sync + help::MarkerWithSuper {} // This can't have no cost without reordering,

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
<del> Subproject commit 3ae62681ff236d5528ef7c8c28ba7c6b2ecc6731 </del> <ins> Subproject commit 2cb0ed9ba56360949f492f9866afe8c293f9f9da </ins>

Discussion:
Compile the above (faulty) code with gives me this:
Probably related to .
Thanks for the information! Close this one.
Change:
} #[test] <del> fn test_stable_push_pop() { </del> <ins> fn test_stable_pointers() { /// Pull an element from the iterator, then drop it. /// Useful to cover both the `next` and `drop` paths of an iterator. fn next_then_drop<I: Iterator>(mut i: I) { i.next().unwrap(); drop(i); } </ins> // Test that, if we reserved enough space, adding and removing elements does not // invalidate references into the vector (such as `v0`).  This test also // runs in Miri, which would detect such problems. <del> let mut v = Vec::with_capacity(10); </del> <ins> let mut v = Vec::with_capacity(128); </ins> v.push(13); <del> // laundering the lifetime -- we take care that `v` does not reallocate, so that's okay. let v0 = unsafe { &*(&v[0] as *const _) }; </del> <ins> // Laundering the lifetime -- we take care that `v` does not reallocate, so that's okay. let v0 = &mut v[0]; let v0 = unsafe { &mut *(v0 as *mut _) }; </ins> // Now do a bunch of things and occasionally use `v0` again to assert it is still valid. <ins> // Pushing/inserting and popping/removing </ins> v.push(1); v.push(2); v.insert(1, 1);

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
<ins> // Regression test for issue #78115: "ICE: variable should be placed in scope earlier" // check-pass // edition:2018 #[allow(dead_code)] struct Foo { a: () } async fn _bar() { let foo = Foo { a: () }; match foo { Foo { a: _a } | Foo { a: _a } if true => {} _ => {} } } fn main() {} </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. --From <!-- 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. --It fails at version: It worked before at version: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Sorry there's no code, but I've narrowed it to somewhere between (working) and (broken).
Likely cause: cc
MCVE: The ICE occurs (inside async blocks or functions) if you're using a match guard and binding the same variable name in both sides of an "or" in a match pattern.
finds a regression in which does correspond to
Assigning .
This ICE is caused here: According to the docs: As we're using a set and a vec in parallel, the ID is pushed twice but stored "only once". Then, we remove it once, and it still exists in the vec but not in the set:
Change:
pub should_fail: ShouldFail, } <ins> unsafe impl Send for TestDesc {} </ins> #[derive(Show)] pub struct TestDescAndFn { pub desc: TestDesc,

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
Change:
/// assert_eq!(merged, "alphabetagamma"); /// ``` /// <ins> /// Flattening works on any `IntoIterator` type, including `Option` and `Result`: /// /// ``` /// let options = vec![Some(123), Some(321), None, Some(231)]; /// let flattened_options: Vec<_> = options.into_iter().flatten().collect(); /// assert_eq!(flattened_options, vec![123, 321, 231]); /// /// let results = vec![Ok(123), Ok(321), Err(456), Ok(231)]; /// let flattened_results: Vec<_> = results.into_iter().flatten().collect(); /// assert_eq!(flattened_results, vec![123, 321, 231]); /// ``` /// </ins> /// Flattening only removes one level of nesting at a time: /// /// ```

Discussion:
While linting my code I came across  which was triggered in my code. This suggests the change from: Into: Both are valid code with same result. But the does not state that this is expected behavior. Yes, this is stated . But this was not strait forward (in my opinion) to find. It took me writing a whole bug report and looking a bunch of thing up to figure this out. (and I'm not even new to Rust anymore) I would suggest adding some example code to make his explicit. Here is a suggestion: (after the section) This makes both this behavior cleared, easier to find and exposes people to code like this so they are less surprised if clippy starts warning them. It looks like this behavior might be more common in the future too. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-doc T-libs.
I'm not sure I like clippy's suggestion, personally, but I think your suggested documentation is reasonable. I would also point out that mapping to / followed by (or a similar ) is better written as (with for ).
I was also confused when I saw the suggestion. But once I realizing what is was doing it sounded in line with things like . That does not mean that I like it, but at least people know it is intended that way and not a side-effect.
I encountered the same clippy warning when iterating over Results, and got perplexed. With the current state of documentation, I personally perceive the warning as suggestion to write obfuscated code hiding the fact that error checking is missing. Adding the documentation change suggested by would make it much easier to realize what flatten() does. Maybe it might be made even more clear how it works if phrasing the first line something like this: Me too am no longer new to Rust, and thought I had a proficient understanding of flatten() after having used it to unroll nested arrays. Likely I'll not be the last person to be surprised it can also be used to discard Err values.
claim
Change:
} ``` <del> PhantomData can also be used to express information about unused type parameters. You can read more about it in the API documentation: </del> <ins> [PhantomData] can also be used to express information about unused type parameters. </ins> <del> https://doc.rust-lang.org/std/marker/struct.PhantomData.html </del> <ins> [PhantomData]: https://doc.rust-lang.org/std/marker/struct.PhantomData.html </ins> "##, E0393: r##"

Discussion:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker
Change:
<del> Subproject commit 5dde0fe6de2941c9ef16bc1e9d91ecf20ac5ee8b </del> <ins> Subproject commit c8713c2f9fc1e28c90876b9ec9557d8c5729757b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Change:
<ins> // Regression test for issue #120615. fn main() { [(); loop {}].field; //~ ERROR constant evaluation is taking a long time } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.
Change:
<ins> fn f() -> f32 { 3 //~^ ERROR expected `;` 5.0 } fn k() -> f32 { 2_u32 //~^ ERROR expected `;` 3_i8 //~^ ERROR expected `;` 5.0 } fn main() {} </ins>

Discussion:
Given the following code (): The current output is: What is this second error trying to tell me? What did it expect to be unit type and why? Does it make sense for this error to be emitted despite the first error correctly identifying my problem? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's trying to tell you nothing in particular. This is a bug, due to the fact that we eat the token and replace it with , so the "fixed" body ends up being:
That theory doesn't seem right to me, for two reasons: I would expect eating the to result in a type error like "expected because of return type", but the actual error involves integer and unit. Repeating the missing-semi error results in repeating the type error as well, even though it's all within one function. : gives two missing-semi errors and two type errors:
The error is reported at this point Then it's considered as recovered, and the are reported at type anlysising phase. Should we treat it as unrecovered, or make the dummy so that type anlysising won't report error messages?
claim
please first understand what the AST doing on the semicolon recovery path, then once that's done, you can probably try to make it recover like: properly so it type-checks correctly.
Change:
if self.is_mutable_static(def_id) { self.mk_mut_ptr(static_ty) <del> } else if self.is_foreign_item(def_id) { self.mk_imm_ptr(static_ty) </del> } else { self.mk_imm_ref(self.lifetimes.re_erased, static_ty) }

Discussion:
root: window - 2 (0 gh, 2 ) detected crates which regressed due to this <detailsbarg-0.2.0: v. window-0.3.0: v. </detailscc
:( is being used . The regression is caused by
Minimal repro: the MIR is The deallocates the array that the call gets a raw pointer to. That's where the dangling pointer error comes from. I guess we used to promote this array but due to the deref (since statics are now ) don't do this anymore
triage: P-high. (Has PR, yay.)
Change:
tempfile = "3" tracing = "0.1" tracing-tree = "0.2.0" <ins> threadpool = "1.8.1" </ins> [dependencies.tracing-subscriber] version = "0.3.3" default-features = false features = ["fmt", "env-filter", "smallvec", "parking_lot", "ansi"] <del> [target.'cfg(windows)'.dependencies] rayon = "1.5.1" </del> [dev-dependencies] expect-test = "1.4.0"

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc