jiebi/CodeConvo huggingface dataset:
Change:
if id == fn_id { match entry_type { config::EntryMain => { <del> let substs = fcx.tcx.mk_substs(iter::once(Kind::from(ret_ty))); </del> <ins> let substs = fcx.tcx.mk_substs(iter::once(Kind::from(declared_ret_ty))); </ins> let trait_ref = ty::TraitRef::new(term_id, substs); let return_ty_span = decl.output.span(); let cause = traits::ObligationCause::new(

Discussion:
we’re stabilizing the combination of features that allows you to put in the return type of main as in . Amusing but unintended so it’s better to forbid this for now.
It's a bit late to change this. Does it cause any problem? AFAICT it just gives you a weird way to declare , but no new capability.
It doesn't give any new capability, I guess would even make sense in the return type of main. This bug could be considered a feature.
cc
Why this is an issue? returns and implements .
does not implement , which is required for the return type of .
Yea, it seems you can use any trait: Works on beta and nightly. So it'll probably work on this weeks stable You can't do anything stupid with this feature. The checks see right through the impl Trait to the real type (). I'd say adding a regression test that ensures that this corner case essentially ignores the anonymization of impl Trait is fine. We can add a deny by default lint that tells you that while this works, it's not pretty.
This seems fine to me and unless we care enough to stop the stable release we're not going to change this. cc though.
Hmm, I feel like we should just fix this. I doubt there are a lot of people taking advantage of it. I can put up some mentoring instructions. We can do a warning period if needed.
Fwiw I tried fixing by doing and got ICEs and stack oveflows which I couldn't debug so I gave up.
Hmm, I don't understand the stack overflows, but I think I would expect that patch to have no effect. The cause of the bug is that we are "instantiating" the impl Trait, here: In the process, we shadow the "original" with a new variable . This new will contain an inference variable used to find the "hidden" type underneath the . Later on, when we add the obligation that (where is the return type), we use this new variable: If we used the original (currently shadowed) , I think it would permit you to use but not other impl traits. (That said, it wouldn't be the end of the world if we just let this go, I suppose.)
As far as I understand we don't want to block 1.26 stable on this, right?

In that case I think we should go with a lint instead of an hard error, since both of the features will be stabilized now.
I probably borked the state of my clone or something. Thanks for the explanation, makes perfect sense, will make a patch.
Change:
tidy: @$(call E, check: formatting) $(Q)find $(S)src -name '*.r[sc]'  <del> | grep '^$(S)src/jemalloc' -v  | grep '^$(S)src/libuv' -v  | grep '^$(S)src/llvm' -v  | grep '^$(S)src/gyp' -v  | grep '^$(S)src/libbacktrace' -v  | xargs -n 10 $(CFG_PYTHON) $(S)src/etc/tidy.py </del> <ins> -and -not -regex '^$(S)src/jemalloc.*'  -and -not -regex '^$(S)src/libuv.*'  -and -not -regex '^$(S)src/llvm.*'  -and -not -regex '^$(S)src/gyp.*'  -and -not -regex '^$(S)src/libbacktrace.*'  -print0  | xargs -0 -n 10 $(CFG_PYTHON) $(S)src/etc/tidy.py </ins> $(Q)find $(S)src/etc -name '*.py'  | xargs -n 10 $(CFG_PYTHON) $(S)src/etc/tidy.py $(Q)find $(S)src/doc -name '*.js' 

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
Applicability::MachineApplicable, ); err.note( <del> "for more on the distinction between the stack and the  heap, read https://doc.rust-lang.org/book/ch15-01-box.html,  https://doc.rust-lang.org/rust-by-example/std/box.html, and  https://doc.rust-lang.org/std/boxed/index.html", </del> <ins> "for more on the distinction between the stack and the heap, read  https://doc.rust-lang.org/book/ch15-01-box.html,  https://doc.rust-lang.org/rust-by-example/std/box.html, and  https://doc.rust-lang.org/std/boxed/index.html", </ins> ); } } <ins> /// When encountering an `impl Future` where `BoxFuture` is expected, suggest `Box::pin`. fn suggest_calling_boxed_future_when_appropriate( &self, err: &mut DiagnosticBuilder<'_>, expr: &hir::Expr<'_>, expected: Ty<'tcx>, found: Ty<'tcx>, ) -> bool { // Handle #68197. if self.tcx.hir().is_const_context(expr.hir_id) { // Do not suggest `Box::new` in const context. return false; } let pin_did = self.tcx.lang_items().pin_type(); match expected.kind { ty::Adt(def, _) if Some(def.did) != pin_did => return false, // This guards the `unwrap` and `mk_box` below. _ if pin_did.is_none() || self.tcx.lang_items().owned_box().is_none() => return false, _ => {} } let boxed_found = self.tcx.mk_box(found); let new_found = self.tcx.mk_lang_item(boxed_found, lang_items::PinTypeLangItem).unwrap(); if let (true, Ok(snippet)) = ( self.can_coerce(new_found, expected), self.sess().source_map().span_to_snippet(expr.span), ) { match found.kind { ty::Adt(def, _) if def.is_box() => { err.help("use `Box::pin`"); } _ => { err.span_suggestion( expr.span, "you need to pin and box this expression", format!("Box::pin({})", snippet), Applicability::MachineApplicable, ); } } true } else { false } } </ins> /// A common error is to forget to add a semicolon at the end of a block, e.g., /// /// ```

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
return false; }; <ins> debug!("subject = {:?}", subject); let r_scc = self.constraint_sccs.scc(*lower_bound); debug!( "lower_bound = {:?} r_scc={:?} universe={:?}", lower_bound, r_scc, self.scc_universes[r_scc] ); // If the type test requires that `T: 'a` where `'a` is a // placeholder from another universe, that effectively requires // `T: 'static`, so we have to propagate that requirement. // // It doesn't matter *what* universe because the promoted `T` will // always be in the root universe. if let Some(p) = self.scc_values.placeholders_contained_in(r_scc).next() { debug!("encountered placeholder in higher universe: {:?}, requiring 'static", p); let static_r = self.universal_regions.fr_static; propagated_outlives_requirements.push(ClosureOutlivesRequirement { subject, outlived_free_region: static_r, blame_span: locations.span(body), category: ConstraintCategory::Boring, }); // we can return here -- the code below might push add'l constraints // but they would all be weaker than this one. return true; } </ins> // For each region outlived by lower_bound find a non-local, // universal region (it may be the same region) and add it to // `ClosureOutlivesRequirement`. <del> let r_scc = self.constraint_sccs.scc(*lower_bound); </del> for ur in self.scc_values.universal_regions_outlived_by(r_scc) { <ins> debug!("universal_region_outlived_by ur={:?}", ur); </ins> // Check whether we can already prove that the "subject" outlives `ur`. // If so, we don't have to propagate this requirement to our caller. //

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> fn main() {} fn attr_in_guard() { match None::<u32> { Some(!) //~ ERROR `!` patterns are experimental if #[deny(unused_mut)] //~ ERROR attributes on expressions are experimental false //~ ERROR a guard on a never pattern will never be run } match false {} } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)', 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)' File: --snippet: 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: [shallowlintlevelson] looking up lint levels for [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in cc
Change:
) -> ProcessResult<PendingPredicateObligation<'tcx>, FulfillmentErrorCode<'tcx>> { let tcx = self.selcx.tcx(); <del> if obligation.predicate.is_global() { </del> <ins> if obligation.predicate.is_global() && !self.selcx.is_intercrate() { </ins> // no type variables present, can use evaluation for better caching. // FIXME: consider caching errors too. if self.selcx.infcx.predicate_must_hold_considering_regions(obligation) {

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 you this assertion
Regression in nightly-2023-07-06 Regression in
so this was clearly buggy before and I expect it to be an issue limited to specialization. Going to not look into this further myself for now.
Change:
<del> error: borrowed data cannot be stored outside of its closure --> $DIR/issue-45983.rs:17:27 | LL |     let x = None; |         - borrowed data cannot be stored into here... LL |     give_any(|y| x = Some(y)); |              ---          ^ cannot be stored outside of its closure |              | |              ...because it cannot outlive this closure error: aborting due to previous error </del>

Discussion:
D'oh: while investigating , I found a case where we are downgrading the NLL errors to warnings (due to the migration mode in ), but AST-borrowck issues an error for the test! (This may explain , at least in part...) Namely, . Here is the test: Here is the AST-borrowck output (a hard error): And here is the NLL output (another hard error): But here is the output from : ui/borrowck/issue- is one particular instance of this, but now that I've found one, I'm certain there are more. This is pretty bad. Very high priority to fix.
This code looks suspicious:
Ha I should have just left this to to fix, since we seem to have independently identified the culprit.
I think I've already assigned myself to enough issues.
Change:
<ins> error: missing expression to iterate on in `for` loop --> $DIR/missing-expression-in-for-loop.rs:2:14 | LL |     for i in { |              ^ | help: try adding an expression to the `for` loop | LL |     for i in /* expression */ { |              ++++++++++++++++ error: aborting due to previous error </ins>

Discussion:
Spot the bug: Unfortunately, instead of pointing to the missing iterator, rust points to the 1: I'd love it to instead say 'missing iterator for loop': Other variants of this with less than ideal errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Well, it thinks the block is the iterator.
Yes, I understand, but a) is not an iterator, and b) since there's no body of the loop I was hoping the parser could recover somehow and understand that the block expression was intended to be the body.
Yes, I just wanted to make sure we were on the same page :)
I could have sworn there was an old ticket for this already but I can't find it
claim
Change:
<del> //@ known-bug: #122989 trait Traitor<const N: N<2> = 1, const N: N<2> = N> { fn N(&N) -> N<2> { M } } trait N<const N: Traitor<2> = 12> {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:35 ~ [f939]::N).1), defid: DefId(0:37 ~ [f939]::N::{constant}), body: BodyId { hirid: HirId(DefId(0:35 ~ [f939]::N).2) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:35 ~ [f939]::N).1), defid: DefId(0:37 ~ [f939]::N::{constant}), body: BodyId { hirid: HirId(DefId(0:35 ~ [f939]::N).2) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [paramenv] computing normalized predicates of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
bisects to
Slightly smaller:
Change:
Path, QPath, Stmt, StmtKind, TyKind, WherePredicate, }; use rustc_hir_analysis::astconv::AstConv; <del> use rustc_infer::traits::{self, StatementAsExpression}; </del> <ins> use rustc_infer::traits::{self}; </ins> use rustc_middle::lint::in_external_macro; use rustc_middle::middle::stability::EvalResult; use rustc_middle::ty::print::with_no_trimmed_paths;

Discussion:
The code below has superfluous semicolons in the branches of the if expression: The error message that results is: This can be confusing to beginners, who may not understand unit type. However, since the expressions and can be shown to have no side effects, the code (as is) can't be what the user intended. Could the compiler produce a more targeted error message that mentions the superfluous semicolon? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-compiler A-diagnostics D-newcomer-roadblock D-terse
claim
Thinking more about this, I don't think we should extend the "remove semicolon to make tail expression" suggestion to cover this case, since we don't know the expected type of at the point at which the suggestion would be made. For example, we don't make the suggestion to change to here: But that's just a guess based on my limited knowledge of type mismatch suggestions. Maybe someone else could weigh in?
Change:
b')' => { depth -= 1; if depth == 0 { <del> return (i, &contents_from[..=j]); </del> <ins> return Some((i, &contents_from[..=j])); </ins> } } _ => { } } } <del> unreachable!() </del> <ins> // if the parentheses are unbalanced just ignore this cfg -- it'll be caught when attempting // to run the compiler, and there's no real reason to lint it separately here None </ins> }).collect() }

Discussion:
Adding some with unbalanced parens in some file in the rust directory makes fail with the following error and backtrace: Which is rather unhelpful.
Looking at means, that should be (or similar) If that wording is okay, I would go and file a PR
Rather than panicking, it would be better to throw an error (e.g. using ). (I think would read slightly better.)
Note that there are other cases where there is an error message like: It seems like we should get the same here too. Edit: Come to think of it, this one might be coming from the compiler.
We could just ignore s with unbalanced parentheses in tidy, as they'll be picked up during compilation. In that case, removing the and adding a comment to that effect should be enough.
Change:
fs::unlink(&bc); } <del> // Now that we've added files, some platforms need us to now update // the symbol table in the archive (because some platforms die when // adding files to the archive without symbols). a.update_symbols(); </del> <ins> // After adding all files to the archive, we need to update the // symbol table of the archive. This currently dies on OSX (see // #11162), and isn't necessary there anyway match sess.targ_cfg.os { abi::OsMacos => {} _ => { a.update_symbols(); } } </ins> } None => {}

Discussion:
I'm having trouble building rust on master lately. Here's the entire error: I tracked it down to this pull request: Commenting out the attribute makes rust compile successfully for me. I am on OSX 10.8.4, x86_64
told me on IRC that I should ping you on this.
I find it very odd that commenting out an attribute would fix this. I've seen this problem before, but it's totally unrelated to finalizers in . I have seen this in the past trip up because we're adding files to archives that aren't object files, but I've also heard that this was all previously fixed... I wish I could research more into this, but I can't reproduce this at all on any machine I have.
Yes, it does seem pretty inexplicable, but I thought you might have a clue. I am content with the commenting out the attribute for the time being, so I can at least track master. But I could try to debug this myself if I knew where to start..
Editing title to reflect the real problem here as found out by
Also, hints that uninstalling the system LLVM is a workaround for this.
Seems to be non-trivial to remove LLVM on OSX, after having installed it. I tried moving all llvm-related libs I could fine out of my , but that didn't seem to make a difference.
We may be able to just not run on OSX because it appeared to bootstrap just fine. I think maybe the linkers on linux may need this, but perhaps the ones on OSX are more controlled such that we may not need it. I haven't investigated it much, but it's one possible solution for this.
I'm having this issue as well. I'm not sure I want to try to uninstall my system LLVM, given that it's very likely to break Xcode.
Any idea how I can try disabling the "ar s" execution? I can't seem to find it. It's very hard to grep for. :P
+1, I'm also having this problem (and can't build on OSX 10.9 because of it)
Just wanted to point out that this is still failing with the same error on my machine, which I assume is because the stage0 snapshot is from 3 days before this commit went in. I'll check back when this makes it into the stage0 snapshot.

Yep, still fails to compile on OSX 10.9 with LLVM 3.3 installed. How often are snapshots updated?
A new snapshot is scheduled in (currently third in the queue).
This error was resolved for me with the new snapshot .
This is resolved for me as well.
Change:
fn feed_hir(feed: &TyCtxtFeed<'_, LocalDefId>) { feed.local_def_id_to_hir_id(HirId::make_owner(feed.def_id())); <ins> let node = hir::OwnerNode::AssocOpaqueTy(&hir::AssocOpaqueTy {}); let bodies = Default::default(); let attrs = hir::AttributeMap::EMPTY; let (opt_hash_including_bodies, _) = feed.tcx.hash_owner_nodes(node, &bodies, &attrs.map); </ins> feed.opt_hir_owner_nodes(Some(feed.tcx.arena.alloc(hir::OwnerNodes { <del> opt_hash_including_bodies: None, </del> <ins> opt_hash_including_bodies, </ins> nodes: IndexVec::from_elem_n( hir::ParentedNode { parent: hir::ItemLocalId::INVALID,

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [associatedtypeforimpltraitintrait] creating the associated item corresponding to the opaque type [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items 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 --
This will probably make a simple crash in a lot of cases :3
cc
minimal repro:
Hmm, when writing I tried to trigger the case by enabling , but it didn't ICE. I'll check what is the difference with what cargo does.
Fixed in
A workaround to this issue should be to use or which should disable incremental compilation.
run on nightly rust also  but. if you use to switch stable version rust will be run will successful
There’s also an environment variable to control incremental compilation, so you could set CARGO_INCREMENTAL=0 to do that.
I think this error should be completely fixed, otherwise it will still fail to compile in the IDE environment and the automatic build environment of GitHub Action
Sure, we were just offering a workaround to unblock people temporarily. The fix is already present on master and should be available in tomorrow’s nightly.
Oh, this is great