jiebi/CodeConvo huggingface dataset:
Change:
a vector or string type") }; <del> // FIXME #3169: This is a little odd but it arises due to a // weird wrinkle in LLVM: it doesn't appear willing to let us // call LLVMConstIntGetZExtValue on the size element of the // slice, or seemingly any integer-const involving a sizeof() // call. Despite that being "a const", it's not the kind of // const you can ask for the integer-value of, evidently. This // might be an LLVM bug, not sure. In any case, to work around // this we obtain the initializer and count how many elements it // has, ignoring the length we pulled out of the slice. (Note // that the initializer might be a struct rather than an array, // if enums are involved.) This only works because we picked out // the original globalvar via const_deref and so can recover the // array-size of the underlying array (or the element count of // the underlying struct), and all this will hold together // exactly as long as we _don't_ support const sub-slices (that // is, slices that represent something other than a whole // array).  At that point we'll have more and uglier work to do // here, but for now this should work. // // In the future, what we should be doing here is the // moral equivalent of: // // let len = llvm::LLVMConstIntGetZExtValue(len) as u64; // // but we might have to do substantially more magic to // make it work. Or figure out what is causing LLVM to // not want to consider sizeof() a constant expression // we can get the value (as a number) out of. let len = llvm::LLVMGetNumOperands(arr) as u64; </del> <ins> let len = llvm::LLVMConstIntGetZExtValue(len) as u64; </ins> let len = match ty::get(bt).sty { ty::ty_estr(*) => {assert len > 0; len - 1}, _ => len

Discussion:
Currently the consts translation pass can only handle indexing into a slice if it represents an entire vec, not a sub-vec thereof. Since we don't (presently) have any syntax for making a sub-slice as a const expr, this isn't a big deal. Yet. But it might become one in the future. If so, we need to do a fair bit more work in the const translator, since it appears LLVM doesn't want to feed us back the number-values of consts that depend in any way on the size of a datum. Such as, say, a size bound. Awkward.
Change:
PatKind::TupleStruct(hir::QPath::Resolved(_, ref path), ..) | PatKind::Struct(hir::QPath::Resolved(_, ref path), ..) => { match path.def { <del> Def::Err => return Err(()), </del> <ins> Def::Err => { debug!("access to unresolvable pattern {:?}", pat); return Err(()) } </ins> Def::Variant(variant_did) | Def::VariantCtor(variant_did, ..) => { // univariant enums do not need downcasts

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
("armv7s-apple-ios", armv7s_apple_ios), ("x86_64-apple-ios-macabi", x86_64_apple_ios_macabi), ("aarch64-apple-ios-macabi", aarch64_apple_ios_macabi), <ins> ("aarch64-apple-ios-sim", aarch64_apple_ios_sim), </ins> ("aarch64-apple-tvos", aarch64_apple_tvos), ("x86_64-apple-tvos", x86_64_apple_tvos),

Discussion:
Currently in our application we cannot run the iOS simulator on M1 machines because it is expecting architecture. Forcing using the target can build the project and ship the application but this targets the iOS Device SDK, and will not build in the simulator for testing with this error: should provide an target that uses the iOS Simulator SDK.
Is relevant at all? Can the same path be followed?
Awesome find I'll try doing this! If successful I'll open a similar PR :)
Ran into this now too. Happy to help here as well. Did you already get started?
I did but having trouble I've pushed my changes here: More than happy to work with you on this Jan!
I'll try to get a dev environment set up and then I'll take a look.
I built the toolchain successfully, but when I try to compile my project (with either or ) I'm getting: I think I've missed a setting in the build config I'm using, because the normal nightly compiles fine :( : Edit looks like I will try off :
Yeah, that looks like upstream breakage in because of recent changes. I can try taking your code tomorrow and throw this against my project to see if that fixes my simulator issues.
Yeah I the patch mentioned in that issue and am getting further but: which Xcode still seems to be getting x8664 somewhere: I tried replacing all the with and got closer: but got:
I believe my current version is working but there's something off in my Xcode project that I need to figure out:
Ah, you're building a binary? Yeah, that seems to sort-of work now? I managed to build your branch, my static library is still unchanged. I think we actually need LLVM 12 first to fully enable this ().
It was just a test to see if the simulator is working at all XD. Yeah my file is still saying it's :
Change:
<ins> // check-pass // edition:2018 fn main() {} struct StructA {} struct StructB {} impl StructA { fn fn_taking_struct_b(&self, struct_b: &StructB) -> bool { true } } async fn get_struct_a_async() -> StructA { StructA {} } async fn ice() { match Some(StructB {}) { Some(struct_b) if get_struct_a_async().await.fn_taking_struct_b(&struct_b) => {} _ => {} } } </ins>

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly Needs
Should be fixed by
On current nightly () seems to be fixed (emits only warnings like before): (if this counts as "tested" I can remove )
we should have a proper automated test so this doesn't slip through again
Change:
<ins> // Check that associated types print generic parameters and where clauses. // See issue #67509. // pretty-compare-only // pp-exact:gat-bounds.pp #![feature(generic_associated_types)] trait X { type Y<T>: Trait where Self: Sized; } impl X for () { type Y<T> where Self: Sized = u32; } fn main() { } </ins>

Discussion:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form
Change:
$$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)):  $$(TEST_SREQ$(1)_T_$(2)_H_$(3))  <del> $$(PRETTY_DEPS_$(4)) </del> <ins> $$(PRETTY_DEPS_$(4))  $$(PRETTY_DEPS$(1)_H_$(3)_$(4)) </ins> @$$(call E, run pretty-rpass [$(2)]: $$<) $$(Q)$$(call CFG_RUN_CTEST_$(2),$(1),$$<,$(3))  $$(PRETTY_ARGS$(1)-T-$(2)-H-$(3)-$(4)) 

Discussion:
When trying to do development on the stage1 compiler, I've been hitting a link error. I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler. But we can and should still try to increase the coverage of bors to handle at least building from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
In case anyone is curious, the problem also occurs on Linux. I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , then things proceed just fine. This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)

(I edited the PR description but forgot that github closes issues based on the original commit message.) I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the build itself, and also adding rules that will force bors to gate on continuing to build.
Change:
} } else { if let Err(terr) = self.cx.fully_perform_op( <del> location.to_locations(), </del> <ins> locations, </ins> ConstraintCategory::Boring, self.cx.param_env.and(type_op::ascribe_user_type::AscribeUserType::new( constant.literal.ty(),

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. 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 ( , regressed in the past week) output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --The desired result can be achieved by swapping the order of the two statements and . <!-- 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 --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim
Change:
use crate::clean::{self, ItemId}; use crate::formats::item_type::ItemType; use crate::json::JsonRenderer; <ins> use crate::passes::collect_intra_doc_links::UrlFragment; </ins> impl JsonRenderer<'_> { pub(super) fn convert_item(&self, item: clean::Item) -> Option<Item> {

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. <del> The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. </del> <ins> The enforcement policies listed above apply to all official Rust venues; including all communication channels (Rust Discord server, Rust Zulip server); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. </ins> *Adapted from the [Node.js Policy on Trolling](https://blog.izs.me/2012/08/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).*

Discussion:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.
Change:
debuginfo::create_captured_var_metadata( bcx, def_id.node, <del> cdata_ty, </del> env_pointer_alloca, i, captured_by_ref,

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:use_from_trait_xc.rs extern crate use_from_trait_xc; pub use use_from_trait_xc::Trait; fn main() { match () { Trait { x: 42u } => () //~ ERROR use of trait `Trait` in a struct pattern } } </ins>

Discussion:
Not the best title, but I suppose it somehow summarizes the situation. There's no ICE if I un-comment "use buffer" and prefix Buffer as the comment is suggesting. There's also no ICE if I rename Buffer into anything else. (fun!) rustc 0.13.0-nightly ( 2014-11-11 22:37:05 +0000) binary: rustc commit-hash: commit-date: 2014-11-11 22:37:05 +0000 host: x8664-apple-darwin release: 0.13.0-nightly
Change:
<ins> struct Foo; struct Bar; impl From<Bar> for Foo { fn from(_: Bar) -> Self { Foo } } fn qux(_: impl From<Bar>) {} fn main() { qux(Bar.into()); //~ ERROR type annotations needed //~| HELP try using a fully qualified path to specify the expected types //~| HELP consider removing this method call, as the receiver has type `Bar` and `Bar: From<Bar>` trivially holds } </ins>

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
return; } <del> self.type_error_message_str(sp, mk_msg, self.ty_to_str(actual_ty), err); </del> <ins> self.type_error_message_str(sp, |_e, a| { mk_msg(a) }, self.ty_to_str(actual_ty), err); </ins> } fn report_mismatched_types(@mut self, sp: span, e: ty::t, a: ty::t,

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
<ins> fn f() { std::<0>; //~ ERROR expected value } fn j() { std::<_ as _>; //~ ERROR expected value //~^ ERROR expected one of `,` or `>`, found keyword `as` } fn main () {} </ins>

Discussion:
Crashes when running . <!-- 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-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]:
Change:
self_ty, deref.hir_id, probe::ProbeScope::TraitsInScope, <del> ); </del> <ins> ) else { return; }; </ins> let other_methods_in_scope: Vec<_> = in_scope_methods.iter().filter(|c| c.item.def_id != pick.item.def_id).collect(); <del> let all_methods = self.probe_for_name_many( </del> <ins> let Ok(all_methods) = self.probe_for_name_many( </ins> probe::Mode::MethodCall, path.ident, Some(expected),

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim