jiebi/CodeConvo huggingface dataset:
Change:
Array(..) | BorrowedRef { type_: box Array(..), .. } => Some(PrimitiveType::Array), Tuple(..) => Some(PrimitiveType::Tuple), RawPointer(..) => Some(PrimitiveType::RawPointer), <ins> BorrowedRef { type_: box Generic(..), .. } => Some(PrimitiveType::Reference), </ins> _ => None, } }

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-109188.rs:17:13 | LL |         let Either::One(_t) = x; |             ^^^^^^^^^^^^^^^   - this expression has type `()` |             | |             expected `()`, found `Either` error[E0308]: mismatched types --> $DIR/issue-109188.rs:18:13 | LL |         let Either::Two(_t) = x; |             ^^^^^^^^^^^^^^^   - this expression has type `()` |             | |             expected `()`, found `Either` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </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
searched toolchains through Regression in
Alternative: As long as the variants for and are different.
label +S-bug-has-mcve
This ICE caused by different root cause.
Change:
<ins> #[forbid(deprecated_pattern)]; </ins> extern mod std; // These tests used to be separate files, but I wanted to refactor all

Discussion:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here
Change:
} }; let ptr = MemoryPointer::new(alloc, 0).into(); <ins> // always try to read the value and report errors </ins> let value = match ecx.try_read_value(ptr, layout.align, layout.ty)? { <del> Some(val) => val, </del> <ins> // if it's a constant (so it needs no address, directly compute its value) Some(val) if !is_static => val, // point at the allocation </ins> _ => Value::ByRef(ptr, layout.align), }; Ok((value, ptr, layout.ty))

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
pub enum CtfeValidationMode { /// Validation of a `static` Static { mutbl: Mutability }, <del> /// Validation of a `const` (including promoteds). </del> <ins> /// Validation of a promoted. Promoted, /// Validation of a `const`. </ins> /// `allow_immutable_unsafe_cell` says whether we allow `UnsafeCell` in immutable memory (which is the /// case for the top-level allocation of a `const`, where this is fine because the allocation will be /// copied at each use site). <del> Const { allow_immutable_unsafe_cell: bool, allow_extern_static_ptrs: bool }, </del> <ins> Const { allow_immutable_unsafe_cell: bool }, </ins> } impl CtfeValidationMode { fn allow_immutable_unsafe_cell(self) -> bool { match self { CtfeValidationMode::Static { .. } => false, <ins> CtfeValidationMode::Promoted { .. } => false, </ins> CtfeValidationMode::Const { allow_immutable_unsafe_cell, .. } => { allow_immutable_unsafe_cell }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: compile fine, with the static containing a slice that references . Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- Provide the version you are using that has the regression. --:
searched nightlies: from nightly-2024-02-10 to nightly-2024-02-11 regressed nightly: nightly-2024-02-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
Context for how I found this: I use this technique in in code generation for benchmarks of generic functions. The simple example I gave is just a minimal reproduction of the issue.
Hm, that is very strange. Not sure if there is a good way to get the backtrace of where in the code the cyclic queries are made? My first guess is that it is the new call to here: But... surely we can ask for the type of a static while evaluating that very static, that can't be cyclic?
Ah no, probably it is related to the fact that we now recursively validate when a constant points to a static. Previously we stopped there. I guess we should not do that for promoteds.
WG-prioritization assigning priority (). label -I-prioritize +P-high -E-needs-bisection +T-compiler
Change:
var_parent: None, }, terminating_scopes: Default::default(), <ins> pessimistic_yield: false, fixup_scopes: vec![], </ins> }; let body = tcx.hir().body(body_id);

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
Does this issue still occur? I couldn't reproduce it from given code on playground.
I just checked with nightly 2019-06-03, and it's still there. It requires the line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.
Change:
out.push_str("</div>"); } } <del> // Recurse into any further impls that might exist for `target` if let Some(target_did) = target.def_id_full(c) { if let Some(target_impls) = c.impls.get(&target_did) { if let Some(target_deref_impl) = target_impls .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(c) == c.deref_trait_did) { sidebar_deref_methods(cx, out, target_deref_impl, target_impls); } } } </del> } }

Discussion:
I don't have time to make an MCVE right now. Stable and beta: ! Nightly and 1.51: ! 50: ! Either the methods should be documented, or they shouldn't be linked to. cc I suspect this is regression from the backports of
First of all, here's an MVCE: Nevermind, I see this is getting discussed in
Removed , this is not a 1.53 regression.
sure, then it's a stable-to-stable regression then. It first regressed in 1.52.
Change:
checked_ty: Ty<'tcx>, expected: Ty<'tcx>, ) -> Option<(Span, &'static str, String, Applicability)> { <del> let sm = self.sess().source_map(); </del> <ins> let sess = self.sess(); </ins> let sp = expr.span; <del> if sm.is_imported(sp) { // Ignore if span is from within a macro #41858, #58298. We previously used the macro // call span, but that breaks down when the type error comes from multiple calls down. </del> <ins> // If the span is from an external macro, there's no suggestion we can make. if in_external_macro(sess, sp) { </ins> return None; } <ins> let sm = sess.source_map(); </ins> let replace_prefix = |s: &str, old: &str, new: &str| { s.strip_prefix(old).map(|stripped| new.to_string() + stripped) };

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
<ins> // check-pass // compile-flags: -Cdebuginfo=2 // fixes issue #94149 #![allow(dead_code)] pub fn main() { let _ = Foo::<dyn FooTrait>::new(); } pub struct Foo<T: FooTrait + ?Sized> { base: FooBase, value: T, } impl<T: FooTrait + ?Sized> Foo<T> { pub fn new() -> Box<Foo<T>> { todo!() } } pub trait FooTrait {} pub struct FooBase { cls: Bar, } // Bar *must* be a fieldless enum pub enum Bar {} </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. --glacier <!-- 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: you need a build with rustc debug assertions enabled! <!-- 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 --
claim
Change:
<ins> // check-pass use std::borrow::Borrow; trait TNode: Sized { type ConcreteElement: TElement<ConcreteNode = Self>; } trait TElement: Sized { type ConcreteNode: TNode<ConcreteElement = Self>; } trait DomTraversal<N: TNode> { type BorrowElement: Borrow<N::ConcreteElement>; } #[allow(dead_code)] fn recalc_style_at<E, D>() where E: TElement, D: DomTraversal<E::ConcreteNode>, { } fn main() {} </ins>

Discussion:
Trait bounds on associated types seem to be required, not implied, when the trait in question mentions an associated type on a type parameter. Concretely, this code (or ) produces an error: despite the bound being required by the definition of itself, and in fact this means that the trait can never be mentioned. This similar example () that doesn't use an associated type in the trait parameter compiles: while this version (), which uses a third trait to avoid the self-reference, does not: Is this just a missing normalization step?
Pretty sure I encountered the same bug when specifying an associated type explicitly in a signature.
/cc you wanted to ensure this test case fell into the trait system rewrite.
I've just run into this as well, it seems. Here's a very simple example:

See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:
Change:
<ins> // build-pass // compile-flags:-Copt-level=0 // edition:2018 struct S<T>(std::marker::PhantomData<T>); impl<T> std::ops::Deref for S<T> { type Target = T; fn deref(&self) -> &Self::Target { todo!() } } impl<T> std::ops::DerefMut for S<T> { fn deref_mut(&mut self) -> &mut Self::Target { todo!() } } async fn new() -> S<u64> { todo!() } async fn crash() { *new().await = 1 + 1; } fn main() { let _ = crash(); } </ins>

Discussion:
Hey, This code attempts to increment a integer behind a tokio RwLock by 1, This causes a compiler error. Minimized example that reproduces the ICE: But, making this very small modification makes the code not break the compiler my contains as a dependency. This code does not compile, and generates the following error (full backtrace in bottom of the issue) rustc --version --verbose also breaks the same way on (the traces attached are from nightly ^) rustup run stable rustc --version -v
Confirmed this also breaks the same way on
MCVE: Fun fact: changing to doesn't ICE. Also I can't inline an instance into the function. It has to be created outside?!. Weird stuff somtimes. Also it would be nice to get rid of the deref, but I couldn't figure out how. So it's on this currently. Also worth mentioning: this needs . isn't sufficient. modify labels: -E-needs-mcve +E-needs-bisection
The bisection doesn't emit anything useful. This panics like forever. I went back to 2019-01-01 (with the old API and stuff) and it still ICEs there, so I guess it was like this forever. Feel free to add the tag again, but I'll remove it. modify labels: -E-needs-bisection
modify labels: -E-needs-bisection
Change:
impl<'tcx> EnclosingBreakables<'tcx> { fn find_breakable(&mut self, target_id: hir::HirId) -> &mut BreakableCtxt<'tcx> { <del> let ix = *self.by_id.get(&target_id).unwrap_or_else(|| { </del> <ins> self.opt_find_breakable(target_id).unwrap_or_else(|| { </ins> bug!("could not find enclosing breakable with id {}", target_id); <del> }); &mut self.stack[ix] </del> <ins> }) } fn opt_find_breakable(&mut self, target_id: hir::HirId) -> Option<&mut BreakableCtxt<'tcx>> { match self.by_id.get(&target_id) { Some(ix) => Some(&mut self.stack[*ix]), None => None, } </ins> } }

Discussion:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.
Change:
<ins> fn main() { something_later!(); //~ ERROR cannot find macro `something_later` in this scope } macro_rules! something_later { () => { println!("successfully expanded!"); }; } </ins>

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
fn visit_struct_field(&mut self, s: &StructField) { self.annotate(s.node.id, &s.node.attrs, |v| visit::walk_struct_field(v, s)); } <ins> fn visit_foreign_item(&mut self, i: &ast::ForeignItem) { self.annotate(i.id, &i.attrs, |_| {}); } </ins> } impl Index {

Discussion:
This may be a duplicate, but can't find the original if it exists. See for the problem. Most of the intrinsics are doc'd with stability markers, but none of that shows up. Docs also consequently don't show up in re-exports.
Uh, are you sure? The doesn't seem to have stability markers at all. Reexports would be a different story though.
The copy_memory ones do.
Ah, you are right. It seems that any extern fns (and not only ) with stability markers are missing them.
To clarify: functions declared inside an block are missing stability markers. Extern functions have them. That is:
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Change:
others.appendChild(div); } <del> function block(shortty, longty) { </del> <ins> /** * Append to the sidebar a "block" of links - a heading along with a list (`<ul>`) of items. * * @param {string} shortty - A short type name, like "primitive", "mod", or "macro" * @param {string} id - The HTML id of the corresponding section on the module page. * @param {string} longty - A long, capitalized, plural name, like "Primitive Types", *                          "Modules", or "Macros". */ function block(shortty, id, longty) { </ins> var filtered = items[shortty]; if (!filtered) { return;

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
<ins> // Copyright 2014 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. // Checks that mutable static items can have mutable slices static mut TEST: &'static mut [int] = &mut [1]; pub fn main() { unsafe { TEST[0] += 1; assert_eq!(TEST[0], 2); } } </ins>

Discussion:
This line in my project currently causes an unimplemented expression error, told me to submit an issue