jiebi/CodeConvo huggingface dataset:
Change:
self.check_for_for_in_in_typo(self.prev_token.span); let expr = self.parse_expr_res(Restrictions::NO_STRUCT_LITERAL, None)?; <del> let pat = self.recover_parens_around_for_head(pat, &expr, begin_paren); </del> <ins> let pat = self.recover_parens_around_for_head(pat, begin_paren); </ins> let (iattrs, loop_block) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs);

Discussion:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.
Change:
LL |     MyTrait2::my_fn(); |     ^^^^^^^^^^^^^^^ cannot call associated function of trait | <del> help: use a fully-qualified path to a specific available implementation (2 found) </del> <ins> help: use a fully-qualified path to a specific available implementation </ins> | LL |     </* self type */ as MyTrait2>::my_fn(); |     +++++++++++++++++++         +

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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
// return type, which can't depend on the obligation. fn cycle1() -> impl Clone { //~^ ERROR cycle detected <del> //~| ERROR cycle detected //~| ERROR cycle detected </del> send(cycle2().clone()); //~^ ERROR cannot be sent between threads safely

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
#![allow(dead_code)] <del> fn foo<F: Fn<(), ()>>(mut f: F) { </del> <ins> fn foo<F: Fn()>(mut f: F) { </ins> f.call(()); //~ ERROR explicit use of unboxed closure method `call` f.call_mut(()); //~ ERROR explicit use of unboxed closure method `call_mut` f.call_once(()); //~ ERROR explicit use of unboxed closure method `call_once`

Discussion:
We do not expect to completely "unfeature-gate" unboxed closures for 1.0. We wish to reserve the flexibility to change a few aspects: to variadic generics in place of auto-tupling. the and arguments from input types to (possibly) associated types. (cc ) the coherence story with respect to fn-trait hierarchy. (cc ) To this end we will adjust the features to: [ ] Disallow references to the traits using angle bracket notation [x] Disallow user impls of the traits [x] Disallow direct calls to [x] Disallow parenthetical notation () from being used with anything other than the traits In short, we permit unboxed closures to be used as if they are a language builtin, but disallow (for now) a lot of the more generic uses. We should be able to drop this feature gate shortly after 1.0. cc
Nominating for 1.0 or something. :)
P-backcompat-lang, 1.0.
Note that some of this works today though it ought not, e.g. manually implementing traits.
To expand on comment, the following code fails to compile due to the lack of a feature that should be gated: The current solution is to put on the function.
This was done, or done enough.
Oops, I totally overlooked that is still considered legal. It's important to adjust that too!
Change:
// Not all raw pointers are allowed, as we cannot properly test them for // equality at compile-time (see `ptr_guaranteed_cmp`). // However we allow those that are just integers in disguise. <del> // (We could allow wide raw pointers where both sides are integers in the future, // but for now we reject them.) let Ok(val) = ecx.read_scalar(place) else { </del> <ins> // First, get the pointer. Remember it might be wide! let Ok(val) = ecx.read_immediate(place) else { </ins> return Err(ValTreeCreationError::Other); }; <ins> // We could allow wide raw pointers where both sides are integers in the future, // but for now we reject them. if matches!(val.layout.abi, Abi::ScalarPair(..)) { return Err(ValTreeCreationError::Other); } let val = val.to_scalar(); </ins> // We are in the CTFE machine, so ptr-to-int casts will fail. // This can only be `Ok` if `val` already is an integer. let Ok(val) = val.try_to_int() else {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Got a scalar pair where a scalar was expected', 'error: internal compiler error: Got a scalar pair where a scalar was expected' File: --code: 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
Regression in nightly-2023-11-09 ping
Good catch, thanks! should fix this.
Change:
<ins> fn test1() { let _v: i32 = (1 as i32).to_string(); //~ ERROR mismatched types // won't suggestion let _v: i32 = (1 as i128).to_string(); //~ ERROR mismatched types let _v: &str = "foo".to_string(); //~ ERROR mismatched types } fn test2() { let mut path: String = "/usr".to_string(); let folder: String = "lib".to_string(); path = format!("{}/{}", path, folder).as_str(); //~ ERROR mismatched types println!("{}", &path); } fn main() { test1(); test2(); } </ins>

Discussion:
I tried this code (): I expected to see this happen: Instead, this happened: This is just a very specific instance where the suggestion to add some code, while "technically correct", is less useful than the better suggestion to remove some code. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
it seems that given an expression, you can generically check if removing the last method call if present would give you the right type, so this could be implemented in a very generic way instead of special casing &str/String.
This looks awesome, thank you so much!
This is how it looks now . Very cool.
Change:
.rusttest { display: none; } pre.rust { position: relative; } <del> .test-arrow { </del> <ins> a.test-arrow { </ins> display: inline-block; position: absolute; <del> top: 0; right: 10px; font-size: 150%; -webkit-transform: scaleX(-1); transform: scaleX(-1); </del> <ins> background-color: #4e8bca; color: #f5f5f5; padding: 5px 10px 5px 10px; border-radius: 5px; font-size: 130%; top: 5px; right: 5px; </ins> } .methods .section-header {

Discussion:
The linkable icon is difficult to . I'm playing with this currently. I'm toying with trying to change the icon from unicode into a svg because unicode has a weird box border shape that doesn't allow the icon to scale to the full box size. I'll put up a PR if I get it working. !
Change:
<ins> /// This will be referred to by the test docstring pub struct Something; </ins>

Discussion:
/cc
So the explosion is that somehow the crate index in the is broken, or at least not entirely right. Interestingly if you add to the then it no longer ICEs (but has the same ) Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both and prevent the iCE)
Maybe it's linked to ? If so, it's not in rustdoc but below.
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the instance. Since was made optional, and crate names are automatically part of the global scope, people stopped necessarily telling the compiler about the crates in their code. If a comment references a path in this manner, but the code itself doesn't, then the resolver frozen into the doesn't have that crate's metadata loaded into it. When we then ask the resolver to resolve a new path (e.g. ) it goes ahead and loads the crate into a different instance of the than will be used when we then try and use the later. It feels like the moment a is d it should also be locked so that it can never be modified again. It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, , I feel this is probably either a bug in how is handling the resolver, or else a change in how the resolver behaves which either needs fixing, or changing in to cope.
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: and instead try and find a resolver as part of the closure here: Of course, it looks like a has an immutable copy of the resolver's outputs, and no access to the resolver itself, urgh, and we have no easy way to inject changes into the context at this point.
I wonder why that type can be cloned in the first place...

I found an ICE when trying to document the [spirit-log][1] crate on the latest . Skimming through the backtrace, it looks like accessed an invalid index while traversing links within . Steps to reproduce: [1]:
Taking a look.
Actually, it's failing outside of rustdoc so I prefer to let someone else handle it. cc
I think this might be a bug (or at least mismatch between how uses the resolver infrastructure and how it's meant to work). See my comment here:
Change:
.map(|ty| dtorck_constraint_for_ty(tcx, span, for_ty, depth + 1, ty)) .collect(), <del> ty::TyGenerator(def_id, substs, _) => { // Note that the interior types are ignored here. // Any type reachable inside the interior must also be reachable // through the upvars. substs .upvar_tys(def_id, tcx) .map(|ty| dtorck_constraint_for_ty(tcx, span, for_ty, depth + 1, ty)) .collect() </del> <ins> ty::TyGenerator(def_id, substs, _interior) => { // rust-lang/rust#49918: types can be constructed, stored // in the interior, and sit idle when generator yields // (and is subsequently dropped). // // It would be nice to descend into interior of a // generator to determine what effects dropping it might // have (by looking at any drop effects associated with // its interior). // // However, the interior's representation uses things like // TyGeneratorWitness that explicitly assume they are not // traversed in such a manner. So instead, we will // simplify things for now by treating all generators as // if they were like trait objects, where its upvars must // all be alive for the generator's (potential) // destructor. // // In particular, skipping over `_interior` is safe // because any side-effects from dropping `_interior` can // only take place through references with lifetimes // derived from lifetimes attached to the upvars, and we // *do* incorporate the upvars here. let constraint = DtorckConstraint { outlives: substs.upvar_tys(def_id, tcx).map(|t| t.into()).collect(), dtorck_types: vec![], overflows: vec![], }; debug!("dtorck_constraint: generator {:?} => {:?}", def_id, constraint); Ok(constraint) </ins> } ty::TyAdt(def, substs) => {

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
pub fn do_postorder_cnums_untracked(&self) -> Vec<CrateNum> { let mut ordering = Vec::new(); <del> for (&num, _) in self.metas.borrow().iter() { self.push_dependencies_in_postorder(&mut ordering, num); </del> <ins> for (num, v) in self.metas.borrow().iter_enumerated() { if let &Some(_) = v { self.push_dependencies_in_postorder(&mut ordering, num); } </ins> } return ordering }

Discussion:
While investigating the root cause(s) of and discussing (in the IRC chat room) the use of a hashmap mapping crate-numbers to crate-metadata, "why is that not an ?" One word: Legacy. Big time: the field has been a hashmap ever since was introduced, 6.5 years ago in () It should be a useful (and hopefully simple?) exercise to replace the hashmap that is with an .
So is it just replacing the type with? If sow what is the equivalent for insert?
Should be as simple as that
The only way I am seeing to add to an IndexVec is to push to the end at index == len But the hashmap uses the ability to insert at an arbitrary index: So I don't quite see how to make the conversion.
from my quick skimming, is only called from one place: , here: The in that context is always the steadily incremented . So I would suggest removing entirely, and replacing it with a some method that indeed pushes to the end at index == len, as you state, since it seems that will have the same end effect.
BTW if one really did need to support overwriting for arbitrary s, that is easy too, as long as they already exist in the , since supports the method that underlying : ; but I don't think we will need that in this case.
Maybe you want an ?
That's not 100% correct. Crate numbers are assigned in preorder - if a crate (say ) has a dependency (say ), then will get the earlier crate number, then will be loaded, and only then will the metadata for be assigned. But it's ok to use an to handle this.
You are right. I overlooked the fact that we 1. first increment the crate num (reserving the number, like for in your example), then 2. call (which may recursively re-enter ), before finally 3. calling at the end.
Ok, what is the best incantation to test this locally? In the meantime I will open a pr.
Change:
"checksum diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "3c2b69f912779fbb121ceb775d74d51e915af17aaebc38d28a592843a2dd0a3a" "checksum difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "524cbf6897b527295dff137cec09ecf3a05f4fddffd7dfcd1585403449e74198" "checksum digest 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)" = "03b072242a8cbaf9c145665af9d250c59af3b958f83ed6824e13533cf76d5b90" <del> "checksum directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "72d337a64190607d4fcca2cb78982c5dd57f4916e19696b48a575fa746b6cb0f" </del> <ins> "checksum directories 2.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "2ccc83e029c3cebb4c8155c644d34e3a070ccdb4ff90d369c74cd73f7cb3c984" </ins> "checksum dirs 1.0.5 (registry+https://github.com/rust-lang/crates.io-index)" = "3fd78930633bd1c6e35c4b42b1df7b0cbc6bc191146e512bb3bedf243fcc3901" <ins> "checksum dirs-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "937756392ec77d1f2dd9dc3ac9d69867d109a2121479d72c364e42f4cab21e2d" </ins> "checksum dlmalloc 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "f283302e035e61c23f2b86b3093e8c6273a4c3125742d6087e96ade001ca5e63" "checksum either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3be565ca5c557d7f59e7cfcf1844f9e3033650c929c6566f511e8005f205c1d0" "checksum elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "a99a310cd1f9770e7bf8e48810c7bcbb0e078c8fb23a8c7bcf0da4c2bf61a455"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.
Change:
<ins> // Test against ICE in #118111 use std::ops::Index; struct Map<T, F> { f: F, inner: T, } impl<T, F, Idx> Index<Idx> for Map<T, F> where T: Index<Idx>, F: FnOnce(&T, Idx) -> Idx, { type Output = T::Output; fn index(&self, index: Idx) -> &Self::Output { todo!() } } fn main() { Map { inner: [0_usize], f: |_, i: usize| 1_usize }[0]; //~^ ERROR cannot index into a value of type // Problem here is that //   `f: |_, i: usize| ...` // should be //   `f: |_: &_, i: usize| ...` } </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
Regression in nightly-2023-04-20 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests, r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3 ERROR: no CI builds available between and within last 167 days
Oh this might be contained in the first rollup ping reduced a bit: `
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
); } <del> for field in def.fields() { self.process_struct_field_def(field, item.id); self.visit_ty(&field.ty); } </del> <ins> self.nest_tables(item.id, |v| { for field in def.fields() { v.process_struct_field_def(field, item.id); v.visit_ty(&field.ty); } </ins> <del> self.process_generic_params(ty_params, &qualname, item.id); </del> <ins> v.process_generic_params(ty_params, &qualname, item.id); }); </ins> } fn process_enum(

Discussion:
I wasn't sure if it was right to report this here or elsewhere, so here it is for now... Trying to compile with works, but running the from the same toolchain results in the following:
looks like
cc
triage: P-high. Removing nomination label.
Easy way to reproduce. empty project to dependencies RLS Errors: And
although supposedly this has been fixed a couple of days ago, latest nightly rls still crashes on petgraph:
Chances are this has been fixed with Could you please update to the newest nightly now and see if you can reproduce this?
yes this is fixed now, thanks!

RLS cannot build my project, which uses gstreamer. Compiling it normally with rustc works fine. Affected project for reference: I launched RLS manually with
Probably unearthed by
cc
Recompiled everything with , same issue.
works fine.
I’m sure it’s what - it’s an unearthed bug when you pass -Zsave-analysis, hence why it crashes only when using RLS.
I have the same error when using rust nightly and directly or indirectly referencing the crate. The project builds fine but crashes. Steps to reproduce: Create a new project Add to the Run Downgrading to and makes the error go away.
pre-triage: not sure what priority to assign to this. Probably P-high but I want to discuss with team. Leaving I-nominated unprioritized for now.
triage: P-high. Cc (can you take point on this?)
Yup, assigning to myself, shouldn’t be hard to fix
What assistance from others, if any, could help you resolve this issue?
Minimal reproducer (based on petgraph ICE):
Is anyone else available you can offload this bug to?
visiting for triage. Assigning to self to remember to look into this later
So I have a fix that does not ICE but doesn't seem to actually 'fix' the behaviour. The problem is that we can't nest typeck tables for because it doesn't have one because it doesn't have a body; however we hit the assertion when trying to resolve member type when resolving a qualified path using because the DefId paths don't properly match. The fix that I have is not to try to nest when a given NodeId doesn't have associated typecktables but instead use an empty table approach (e.g. used in privacy code). This means we don't hit the assertion but IIUC we can't properly resolve a qualified path this way. I think long-term the solution would be to traverse HIR directly rather than doing so using AST (that's another case where we have a mismatch of nested DefIds for which we can't get typeck tables to properly resolve a ). I'll submit the PR with the fix later today.
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::{TokenStream, TokenTree}; #[proc_macro] pub fn print_tokens(input: TokenStream) -> TokenStream { println!("{:#?}", input); for token in input { println!("{token}"); } TokenStream::new() } </ins>

Discussion:
Current output as of nightly-2023-06-20: The correct output would have . The ToString of procmacro::Literal is the only interface by which proc macros are able to inspect literals. It is supposed to include the entire literal, with quotes and escape sequences and everything as originally appear in the source code. Without this, it is impossible for proc macros to operate correctly on literals. For example, it would currently be impossible for a proc macro to tell the difference between and , but those are not the same token. Mentioning tracking issue: Mentioning since you have worked on this feature in the past. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Does resolve this or is there more?
Not fixed as of rustc 1.73.0-nightly ( 2023-08-02).