jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> // This is a rough approximation that gets us what we want. impl<'self> attr::AttrMetaMethods for &'self Attribute { fn name(&self) -> @str { match **self { Word(ref n) | List(ref n, _) | NameValue(ref n, _) => n.to_managed() } } fn value_str(&self) -> Option<@str> { match **self { NameValue(_, ref v) => Some(v.to_managed()), _ => None, } } fn meta_item_list<'a>(&'a self) -> Option<&'a [@ast::MetaItem]> { None } fn name_str_pair(&self) -> Option<(@str, @str)> { None } } </ins> #[deriving(Clone, Encodable, Decodable)] pub struct TyParam { name: ~str,

Discussion:
Nominating for milestone 5, production-ready
Can't be done without running resolve.
should be optional at most, as sometimes you want to see them
just a bug, removing milestone/nomination.
Still relevant though parenting to metabug on rustdoc_ng
/cc This would involve looking at the visibility of the associated trait and excluding the impl from the list if it's not public.
Didn't find a trait to test it with but it should be done now.
Change:
<ins> #![feature(type_alias_impl_trait)] pub type Opaque<'a> = impl Sized; fn get_one<'a>(a: *mut &'a str) -> Opaque<'a> { a } fn get_iter<'a>() -> impl IntoIterator<Item = Opaque<'a>> { //~^ ERROR:  item does not constrain None::<Opaque<'static>> } fn main() {} </ins>

Discussion:
The following should not compile. Adapted from . This is a quick issue, I did not have the chance to look into it deeper but I guess it affects ATPIT as well. cc
This used to be an error in , but then incorrectly accepted in .
Change:
<ins> fn a() { if let () = () 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn b() { if true 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn c() { loop 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn d() { while true 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn e() { while let () = () 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn f() { for _ in 0..0 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn g() { unsafe 'a {} //~^ ERROR labeled expression must be followed by `:` //~| ERROR expected `{`, found `'a` } fn main() {} </ins>

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: The compiler rejects all these expressions as the lifetimes are in a nonsensical position. Instead, this happened: The compiler accepted the expressions without saying anything This behavior seems to occur since 1.61. 60 and below properly reject the code.
This very likely regressed in , I'll put up a fix in like 30 mins.
For the record -- Bisection points at: found 9 bors merge commits in the specified range commit[0] 2022-02-27UTC: Auto merge of - scottmcm:cfg-out-miri-from-swap, r=oli-obk commit[1] 2022-02-27UTC: Auto merge of - erikdesjardins:more-noundef, r=nikic commit[2] 2022-02-28UTC: Auto merge of - matthiaskrgr:rollup-1jsj0wu, r=matthiaskrgr commit[3] 2022-02-28UTC: Auto merge of - RalfJung:miri, r=RalfJung commit[4] 2022-02-28UTC: Auto merge of - erikdesjardins:more-more-noundef, r=nikic commit[5] 2022-02-28UTC: Auto merge of - cjgillot:inline-fresh-expn, r=oli-obk commit[6] 2022-02-28UTC: Auto merge of - psumbera:sparc64-abi-fix2, r=nagisa commit[7] 2022-02-28UTC: Auto merge of - matthiaskrgr:rollup-d8rj2xv, r=matthiaskrgr commit[8] 2022-02-28UTC: Auto merge of - matthiaskrgr:rollup-xv9y98j, r=matthiaskrgr
label +T-compiler +A-parser +A-lifetimes
Change:
ty_param_name); err.span_label(span, &format!("ambiguous associated type `{}`", assoc_name)); <del> for bound in &bounds { span_note!(&mut err, span, "associated type `{}` could derive from `{}`", ty_param_name, bound); </del> <ins> for span_and_bound in spans.zip(&bounds) { if let Some(span) = span_and_bound.0 { err.span_label(span, &format!("ambiguous `{}` from `{}`", assoc_name, span_and_bound.1)); } else { span_note!(&mut err, span, "associated type `{}` could derive from `{}`", ty_param_name, span_and_bound.1); } </ins> } err.emit(); }

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:
ty::TyBareFn(_, ref f) => ((did, &f.sig).clean(cx), f.unsafety, f.abi), _ => panic!("bad function"), }; <ins> let constness = if csearch::is_const_fn(&tcx.sess.cstore, did) { hir::Constness::Const } else { hir::Constness::NotConst }; </ins> let predicates = tcx.lookup_predicates(did); clean::Function { decl: decl, generics: (&t.generics, &predicates, subst::FnSpace).clean(cx), unsafety: style, <del> constness: hir::Constness::NotConst, </del> <ins> constness: constness, </ins> abi: abi, } }

Discussion:
Doc inclusion / doc reexport does not show properly (example: std::cell::Cell::new). Reexport metabug: rustdoc: Pain points of reexports const fn tracker:
Change:
.. } = options; <ins> let extern_names: Vec<String> = externs.iter().map(|(s,_)| s).cloned().collect(); </ins> // Add the rustdoc cfg into the doc build. cfgs.push("rustdoc".to_string());

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:
<ins> error: unconstrained opaque type --> $DIR/hkl_forbidden4.rs:10:23 | LL | type FutNothing<'a> = impl 'a + Future<Output = ()>; |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `FutNothing` must be used in combination with a concrete type within the same module error: concrete type differs from previous defining opaque type use --> $DIR/hkl_forbidden4.rs:13:1 | LL | async fn operation(_: &mut ()) -> () { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `FutNothing<'_>`, got `{async fn body@$DIR/hkl_forbidden4.rs:13:38: 16:2}` | note: previous use here --> $DIR/hkl_forbidden4.rs:15:5 | LL |     call(operation).await |     ^^^^^^^^^^^^^^^ error[E0792]: expected generic lifetime parameter, found `'any` --> $DIR/hkl_forbidden4.rs:21:1 | LL |   type FutNothing<'a> = impl 'a + Future<Output = ()>; |                   -- this generic parameter must be used with a generic lifetime parameter ... LL | / { LL | | LL | | } | |_^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0792`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected region kind in opaque type: RePlaceholder(!2BoundRegion { var: 0, kind: BrNamed(DefId(0:12 ~ 9DABD1FCA6B4214B1AFB7E3E0DCCB52B1F226FCDBDC62026B721AA5FB17BF76D[c411]::call::'any), 'any) })', 'error: internal compiler error: unexpected region kind in opaque type: RePlaceholder(!2BoundRegion { var: 0, kind: BrNamed(DefId(0:12 ~ 9DABD1FCA6B4214B1AFB7E3E0DCCB52B1F226FCDBDC62026B721AA5FB17BF76D[c411]::call::'any), 'any) })' 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: [mirborrowck] borrow-checking [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc could be related to
yea I have just locally started hitting this in tests/ui/impl-trait/impl-fn-predefined- while rebasing
Change:
let &(ref first_arm_pats, _) = &arms[0]; let first_pat = &first_arm_pats[0]; let span = first_pat.span; <del> span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern"); </del> <ins> struct_span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern") .span_label(span, &format!("irrefutable pattern")) .emit(); </ins> }, hir::MatchSource::ForLoopDesugar => {

Discussion:
From: src/test/compile- Error E0184 needs a span_label, updating it from: To: Bonus: I'm not sure that note is helping, you can probably just remove it.
On it
- I am releasing this one so someone else can take it, but feel free to come grab another one

From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

From: src/test/compile- Error E0164 needs a span_label, updating it from: To:
Change:
// run-fail <del> // error-pattern:panicked at 'Box<Any>' </del> <ins> // error-pattern:panicked at 'Box<dyn Any>' </ins> // ignore-emscripten no processes #![allow(non_fmt_panic)]

Discussion:
() I would’ve expected it to say Relevant point in seems to be . label C-enhancement, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-error-handling
claim
Wow, issues really do go fast. Best of luck, reaganmcf!
Change:
check!(rmdir(dir)); }) <ins> iotest!(fn file_test_walk_dir() { let tmpdir = tmpdir(); let dir = &tmpdir.join("walk_dir"); check!(mkdir(dir, io::UserRWX)); let dir1 = &dir.join("01/02/03"); check!(mkdir_recursive(dir1, io::UserRWX)); check!(File::create(&dir1.join("04"))); let dir2 = &dir.join("11/12/13"); check!(mkdir_recursive(dir2, io::UserRWX)); check!(File::create(&dir2.join("14"))); let mut files = check!(walk_dir(dir)); let mut cur = [0u8, .. 2]; for f in files { let stem = f.filestem_str().unwrap(); let root = stem[0] - ('0' as u8); let name = stem[1] - ('0' as u8); assert!(cur[root as uint] < name); cur[root as uint] = name; } check!(rmdir_recursive(dir)); }) </ins> iotest!(fn recursive_mkdir() { let tmpdir = tmpdir(); let dir = tmpdir.join("d1/d2");

Discussion:
It calls on a vector repeatedly. Example: and are directories with that many files in them. Theoretically this wants a deque.
Would keeping an index be sufficient? Just return and bump each time. It seems to me we don't need any fancy data structure. I can work on this.
That might work, but it does mean that the size of the internal vector grows to be the total number of elements ever touched, rather than just the number of children of recently-walked directories. It would also require cloning each of them. (Maybe not, if it stored internally and returned ...)
What about this. When we run out of space at the end, check if we are using more than half of the vector. If we are, allocate a new one at least twice as large. If we are not, swap all the values to the beginning of the vector. This way we have amortized linear time without needing to use a full blown deque. On Apr 10, 2014 2:14 AM, "Huon Wilson" wrote:
If you can get that to work, I guess so. But really, it would be better/more correct to just use a proper ... if std had access to one.
I am going to guess that taking out of std is undesirable. I can't really think of another way to do this rather than creating a simple . I'll work on it if you think this is acceptable.
"It calls .shift on a vector repeatedly." but it's very slow. Vec/Str need an efficient way to shift() multi-items
This isn't multiple items, it needs to shift the s off one at a time.
( I would be OK with moving deque into a "secret" module inside std and reexporting it from libcollections, however rustdoc doesn't support this nicely just yet.)
How about something along these lines: I didn't test the above, removing syntax errors is left as an exercise to the reader. Edit: Never mind, I see this changes the order that walk_dir guarantees. I'll try and rewrite my proposal tonight to make it emulate the current behaviour.
I'm not sure the current order is important, I don't know though (if it's not important we can probably just use as a stack, which is efficient).

However, if we wish to retain the current order, I really do think the correct solution is to just use a deque, rather than write a complicated specialised data structure for this relatively simple task. (Unless that data structure has other significant benefits, of course. Maybe avoiding the copies from each vec to main deque will be noticably more efficient?)
Change:
<ins> error: values of the type `Example` are too big for the current architecture --> $DIR/too-big-with-padding.rs:13:1 | LL | pub fn lib(_x: Example) {} | ^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
rustc generally detects when a static type is larger than bytes, giving an error that + 10x80000000isize::MAX + 1`): (The is to ensure that an object of size is actually created on the stack.) This is clearly unsound, since it breaks the size invariant of , and since third-party crates may depend on types being no larger than for soundness. However, it's nontrivial to observe unexpected behavior from this using only safe APIs in the standard library, since placing the overlarge type within any other type, even a wrapper, will result in a compile error as expected, and the standard APIs tend to refer to when creating a slice from a reference.
Wow, good catch! Looks like we're doing the check before rounding up to the next multiple of alignment? That's bad.
Change:
|         help: provide a definition for the static: `= <expr>;` error: free static item without body <del> --> $DIR/item-free-static-no-body-semantic-fail.rs:8:1 </del> <ins> --> $DIR/item-free-static-no-body-semantic-fail.rs:9:1 </ins> | LL | static mut C: u8; | ^^^^^^^^^^^^^^^^-

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
<ins> #![feature(generic_const_exprs)] #![allow(incomplete_features)] pub struct Foo<T, const H: T>(T) //~^ ERROR the type of const parameters must not depend on other generic parameters where [(); 1]:; 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. --() <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also tested on the playground: . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels: +A-const-generics +F-genericconstexprs +requires-nightly
Change:
<ins> error: missing optimized MIR for an item in the crate `rmeta_meta` | note: missing optimized MIR for this item (was the crate `rmeta_meta` compiled with `--emit=metadata`?) --> $DIR/auxiliary/rmeta-meta.rs:10:1 | LL | pub fn missing_optimized_mir() { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
The following scenario used to work fine 1.25.0: This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:
Possibly dupe/related to ?
Yea I think this is a dupe, handling over there
The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?
Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate
I've discovered that if I tell the compiler to emit another type along with like this issue goes away. It makes me suspect this piece of code in : I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.
Triage: still repros:
Since , doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.
PR with fix:
Change:
// Propagate state on-exit from node into its successors. self.propagate_bits_into_graph_successors_of(in_out, cfg, node_index); <del> true // continue to next node }); </del> <ins> } </ins> } fn reset(&mut self, bits: &mut [usize]) {

Discussion:
See . Here is a chart giving time output from with of the lines of the form uncommented. n -------- With this gist I've tried to create a fairly minimal example. It's not as minimal as maybe it could be because it's a little tricky to figure out what's causing the slow compiles and I've spent as much time as I can on this right now. It's very sensitive to seemingly irrelevant changes in the code. If I remove the unused variable, compile times dramatically improve. If I remove the empty loop, compile times dramatically improve. On my actual project, I am getting compile times in excess of 20 minutes. To compile a few thousand lines of code.
cc
Umm this is not an expansion problem but rather a borrowck problem - dataflow somehow takes O(n) iterations to converge.
Change:
} impl<'a> Visitor<'a> for ItemLowerer<'a, '_, '_> { <ins> fn visit_attribute(&mut self, _: &'a Attribute) { // We do not want to lower expressions that appear in attributes, // as they are not accessible to the rest of the HIR. } </ins> fn visit_item(&mut self, item: &'a Item) { let hir_id = self.lctx.with_hir_id_owner(item.id, |lctx| { let node = lctx.without_in_scope_lifetime_defs(|lctx| lctx.lower_item(item));

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a few other errors, because the code is nonsense, so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsAlso note how there is one additional error below the backtrace, not sure if that's expected.
Thanks for the bug report, could this be related to the recent HIR map/lowering refactorings?
This issue looks very similar to , but the examples from there don't panic anymore.

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I got a very large poc file, and reduce it into following code. But after reducing (via a simple delta debugging tech), the code looks kind of confusing. Please let me know if anyone prefers a better-formed but long test-case, and I will try me best to get one. md5: <!-- 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 bug is reproduced with nightly and beta versions, but not with stable version. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This can be "solved" by using and create a instead of panicking.
Assigning as discussed as part of the and removing .
A reproduction with fewer errors:
The provided examples do not panic anymore, can this issue be closed or does it need tests?
lets keep it open purely to track adding regression tests for these.