jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error: lifetime may not live long enough --> $DIR/account-for-lifetimes-in-closure-suggestion.rs:13:22 | LL |     Thing.enter_scope(|ctx| { |                        --- |                        | |                        has type `TwoThings<'_, '1>` |                        has type `TwoThings<'2, '_>` LL |         SameLifetime(ctx); |                      ^^^ this usage requires that `'1` must outlive `'2` | = note: requirement occurs because of the type `TwoThings<'_, '_>`, which makes the generic argument `'_` invariant = note: the struct `TwoThings<'a, 'b>` is invariant over the parameter `'a` = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance error: aborting due to 1 previous error </ins>

Related discussion:
text: : <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.
Code change:
<ins> // Copyright 2017 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. // compile-flags: -D warnings -D unknown-lints #![allow(unknown_lints)] #![allow(random_lint_name)] fn main() {} </ins>

Related discussion:
text: The following snippet works fine before but now it reports a warning: Steps to reproduce: clone rustup override set nightly-2017-08-11 cargo test Is this an expected behavior, or a bug? Thank you!
cc -- probably related to the new lint implementation
Yes this was caused by The bug is on . The check for whether is in scope is not checking the current set of attributes being linted. For example this does not warn: but this warns: (as you've noticed) The fix is to just take the local variable into account which has the up-to-that-point set of lint attributes collected.
I've opened a PR for this at
Code change:
#[inline] fn plain_summary_line(s: Option<&str>) -> String { <del> let md = markdown::plain_summary_line(s.unwrap_or("")); shorter(Some(&md)).replace("n", " ") </del> <ins> let line = shorter(s).replace("n", " "); markdown::plain_summary_line(&line[..]) </ins> } fn document(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item) -> fmt::Result {

Related discussion:
text: A documentation comment like the one cited verbatim below, produces a main page summary that includes the first line of the code in the example. This is very surprising since there's an empty line in between, and the code example inserts a large colored box in the overview page (the parent module). cc since it's probably related to PR /// A tuple or fixed size array that can be used to index an array. /// /// /// /// Note the blanket implementation that's not visible in rustdoc: /// !
Code change:
}; debug!("make_shim({:?}) = untransformed {:?}", instance, result); <del> pm::run_passes( </del> <ins> // We don't validate MIR here because the shims may generate code that's // only valid in a reveal-all param-env. However, since we do initial // validation with the MirBuilt phase, which uses a user-facing param-env. // This causes validation errors when TAITs are involved. pm::run_passes_no_validate( </ins> tcx, &mut result, &[

Related discussion:
text: <!-- 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. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted.
Code change:
}; debug!("make_shim({:?}) = untransformed {:?}", instance, result); <del> pm::run_passes( </del> <ins> // We don't validate MIR here because the shims may generate code that's // only valid in a reveal-all param-env. However, since we do initial // validation with the MirBuilt phase, which uses a user-facing param-env. // This causes validation errors when TAITs are involved. pm::run_passes_no_validate( </ins> tcx, &mut result, &[

Related discussion:
text: All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.
Code change:
| LL |     opaque!; |           + <ins> help: a unit struct with a similar name exists | LL |     Opaque; |     ~~~~~~ </ins> error: aborting due to 3 previous errors

Related discussion:
text: Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note suggesting the variant with the same name (but different case):
label +C-enhancement +D-newcomer-roadblock
This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.
im working on this Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.
Okay, judging by , this is explicitly not supposed to work. shrug emoji Edit: Okay, maybe that test case didn't really care. The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with afaict.
Code change:
} } } else if let &Safety::Unsafe(span) = safety { <del> this.dcx().emit_err(errors::UnsafeItem { span, kind: "extern block" }); </del> <ins> let mut diag = this .dcx() .create_err(errors::UnsafeItem { span, kind: "extern block" }); rustc_session::parse::add_feature_diagnostics( &mut diag, self.session, sym::unsafe_extern_blocks, ); diag.emit(); </ins> } if abi.is_none() {

Related discussion:
text: With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?
Code change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/98658> #![no_std] // @has blanket_impls.json // @has - "$.index[*][?(@.name=='Error')].kind" "assoc_type" // @has - "$.index[*][?(@.name=='Error')].inner.default.kind" "resolved_path" // @has - "$.index[*][?(@.name=='Error')].inner.default.inner.name" "Infallible" pub struct ForBlanketTryFromImpl; </ins>

Related discussion:
text: Run with this in : and inspect . There is an item for the of the blanket impl  and it's default value is . There is an item but the default value is missing. It looks like this: When using instead of the information about the default value is present. It looks like this: This change, which in practice is a regression, is caused by But we can't revert it of course because that will result in ICEs which is even worse. So we need some kind of follow-up fix. labels +A-rustdoc-json +T-rustdoc +C-bug +requires-nightly
It seems like you already suggested a fix. Want to open a PR for it?
Yep I will do that as soon as I get time. Probably today.
It's not in a hurry. Don't hesitate to ask if you need help.
Code change:
<del> Subproject commit 3bf51f591f7ffdd45f51cd1d42a4002482af2bd5 </del> <ins> Subproject commit c388361cc2db82568d5e90fefea864f0af8d35e9 </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
This test is failing:
might give a hint what needs to be updated. I haven't gotten a chance to look closely yet.
Yeah, we'll need to emulate that new static thing by Unfortunately I don't entirely understand the static magic that goes on there... there's just a fn ptr stored in a particular section and somehow that is enough?!?
Yes, all platforms have sections that they treat as an array of pointers, filling the entire section, which makes it easy to append more entries, as linkers will happily concatenate sections with the same name. This is how C++ global constructors are implemented everywhere. So I guess there's two levels to this: miri should collect the platform-specific global ctors/dtors (on Linux I think there's also init/fini which work similarly) and execute them before C main (and after, in the case of dtors) when is , the ctors (or just the init flavor?) can also take 1, 2 or 3 arguments, not only 0 arguments (I believe this is also how C main technically works)
Okay. This is basically I hoped we'd never have to do this... For dtors, we already run TLS dtors, but those are entirely separate (we hook the pthread calls where dtors are set, and then run those functions later). There's no way those can be unified to one mechanism, is there? Also, this begs the question in which order stuff is called before/after main.
C++ asks itself the same question and I personally haven't heard of there being an answer. The safe thing to do is to make sure any order is safe (in Rust you have to initialize global state before any runtime initialization, so it's safer than C++ where before the constructor runs, the fields are uninitialized). The implementations just go through the sections in order, so the unknown quantity is what order the linker concatenates all of these sections.
Code change:
<del> Subproject commit 3bf51f591f7ffdd45f51cd1d42a4002482af2bd5 </del> <ins> Subproject commit c388361cc2db82568d5e90fefea864f0af8d35e9 </ins>

Related discussion:
text: In miri you don't have the linker to think about, but you do need a mechanisms to access all statics from all crates.
Wait, why can't libstd initialize the args from the start lang item as well? Surely there's an inexpensive way to do so?
That's what I did originally, but said not to.
Reverting should fix this.
We could either adjust the 's to no use the new method when is set, or we could implement those initializers. Seems like we'll want them eventually anyway... What would be the best way to do that?
In the short term, excluding from the new mechanism seems like a reasonable solution to unbreak miri. That depends on two factors: what order functions get placed into the sections, and what order they get called. The default linker scripts will collect all sections in sorted order, followed by the section itself, into a single section. Likewise for and . The sort order here uses the linker's , which takes a numeric section suffix as a numeric priority, and sorts sections with non-numeric suffixes asciibetically. (There are also a couple of special cases to make sure that glibc can guarantee its own functions run first/last in a couple of those. And there are some very careful special cases to handle the old , , , and sections, which get translated into corresponding , , , and sections respectively in the final binary to preserve the behavior of those sections, keeping in mind that ctors sections get run in reverse order and the dtors sections get run in forwards order. translates the priority in numbered ctors and dtors sections by subtracting it from .) When loading a program or library, glibc calls the function pointers in in order, then the (single) function (which executes the contents of the section), then the function pointers in in order. At shutdown, glibc calls the function pointers in in reverse order, then the (single) function (which executes the contents of the section). Does that help?
It is a great reference, thanks! So far I have no idea how to wire up all these sections in Miri, but I guess we'll see about that. ;) On a separate note, also broke Miri by removing the getter from . I am not sure yet if there is a replacement that we can use instead.
Code change:
<del> Subproject commit 3bf51f591f7ffdd45f51cd1d42a4002482af2bd5 </del> <ins> Subproject commit c388361cc2db82568d5e90fefea864f0af8d35e9 </ins>

Related discussion:
text: Leaving that here just so that I hopefully can find it later.
I don't see any way to actually do that.
I would prefer to avoid duplicate initialization of arguments. I'd like to make Rust executables smaller, not larger.
I agree, I would accept this change.
I opened a PR for that:
Done. I set it to close this issue since we already have to track the more elaborate approach.
Well, actually closing the issue will require also bumping the submodule to include
I don't understand, this would only be a few bytes with ? To unbreak miri it's probably fine but I'm increasingly worried about , as it allows divergence to exist in ways which are not controlled within miri itself.
I was talking about a user of these facilities, not miri implementation. To expand a bit (although it's kind of offtopic): Rust forces you to mutate a that started out with a constant value (e.g. ), which means nothing else would observe an uninitialized value, just the initial constant value, if it happened to ran before the runtime initialization (which would e.g. replace the with a ). This makes Rust + safer in general than C++ with global constructors.
Ack.
Aand now we also need to wait for to land. That's the third independent Miri-breaking PR in 24h, impressive. ;)
Code change:
// build-fail <ins> // revisions: normal mir-opt // [mir-opt]compile-flags: -Zmir-opt-level=4 </ins> trait C { const BOO: usize;

Related discussion:
text: File: /tmp/icemaker/issue--2.rs 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
cc
Code change:
<del> Subproject commit 412fb00b37afb6b7f7fa96a35f2315c7e640b916 </del> <ins> Subproject commit d9aa23a43ad29e3a10551a1425ef5d5baef28d70 </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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.
Upstream fix has landed:
Code change:
// figure out which generic parameter it corresponds to and return // the relevant type. let generics = match path.res { <del> Res::Def(DefKind::Ctor(..), def_id) => { </del> <ins> Res::Def(DefKind::Ctor(..), def_id) | Res::Def(DefKind::AssocTy, def_id) => { </ins> tcx.generics_of(tcx.parent(def_id).unwrap()) } Res::Def(_, def_id) => tcx.generics_of(def_id), <del> Res::Err => return tcx.types.err, </del> res => { tcx.sess.delay_span_bug( DUMMY_SP, <del> &format!("unexpected const parent path def {:?}", res,), </del> <ins> &format!( "unexpected const parent path def, parent: {:?}, def: {:?}", parent_node, res ), </ins> ); return tcx.types.err; }

Related discussion:
text: results in an ICE (): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
impl Deref for Thing { //~^ ERROR not all trait items implemented, missing: `Target` [E0046] fn deref(&self) -> i8 { self.0 } <del> //~^ ERROR method `deref` has an incompatible type for trait: expected &-ptr, found i8 [E0053] </del> <ins> //~^ ERROR method `deref` has an incompatible type for trait //~| expected &-ptr //~| found i8 [E0053] </ins> } let thing = Thing(72);

Related discussion:
text: The multi-line errors should be extended to include this testcase. missed this because the didn't go through . I tried but that didn't work either. If someone can point me to to where to catch it, I can probably fix this too. cc Code: Error: Change to:
Code change:
let mut span = None; let mut accum = 0u64; <del> for (index, arg_def) in fn_sig.inputs().iter().enumerate() { let layout = tcx.layout_of(ParamEnv::reveal_all().and(*arg_def.skip_binder()))?; </del> <ins> // this type is only used for layout computation, which does not rely on regions let fn_sig = tcx.instantiate_bound_regions_with_erased(fn_sig); for (index, ty) in fn_sig.inputs().iter().enumerate() { let layout = tcx.layout_of(ParamEnv::reveal_all().and(*ty))?; </ins> let align = layout.layout.align().abi.bytes(); let size = layout.layout.size().bytes();

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' 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: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc
Code change:
fn visit_item(&mut self, item: &'tcx Item) { let mut item_hir_id = None; self.lctx.with_hir_id_owner(item.id, |lctx| { <del> if let Some(hir_item) = lctx.lower_item(item) { item_hir_id = Some(hir_item.hir_id); lctx.insert_item(hir_item); } </del> <ins> lctx.without_in_scope_lifetime_defs(|lctx| { if let Some(hir_item) = lctx.lower_item(item) { item_hir_id = Some(hir_item.hir_id); lctx.insert_item(hir_item); } }) </ins> }); if let Some(hir_id) = item_hir_id {

Related discussion:
text: The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).
Code change:
self.resolve_expr(elem, Some(expr)); self.visit_expr(idx); } <del> ExprKind::Assign(..) => { let old = self.diagnostic_metadata.in_assignment.replace(expr); visit::walk_expr(self, expr); self.diagnostic_metadata.in_assignment = old; </del> <ins> ExprKind::Assign(ref lhs, ref rhs, _) => { if !self.diagnostic_metadata.is_assign_rhs { self.diagnostic_metadata.in_assignment = Some(expr); } self.visit_expr(lhs); self.diagnostic_metadata.is_assign_rhs = true; self.diagnostic_metadata.in_assignment = None; self.visit_expr(rhs); self.diagnostic_metadata.is_assign_rhs = false; </ins> } _ => { visit::walk_expr(self, expr);

Related discussion:
text: <!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should first check the RHS, before suggest adding . It should also avoid suggesting when code is invalid. Thanks. Something like this should also not suggest adding : cc <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not convinced the second example should be something we need to fix, but the first example should be very easy to fix.
claim