jiebi/CodeConvo huggingface dataset:
Change:
#[naked] pub fn naked_with_args_and_return(a: isize) -> isize { // CHECK-NEXT: {{.+}}: <del> // CHECK-NEXT: %a = alloca i{{[0-9]+}} </del> <ins> // CHECK-NEXT: %_1 = alloca i{{[0-9]+}} </ins> &a; // keep variable in an alloca // CHECK: ret i{{[0-9]+}} %{{[0-9]+}} a

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
/// * Pointers to allocations inside of statics can never leak outside, to a non-static global. /// This boolean here controls the second part. pub(super) can_access_statics: bool, <ins> /// Whether to check alignment during evaluation. check_alignment: bool, </ins> } impl<'mir, 'tcx> CompileTimeInterpreter<'mir, 'tcx> { <del> pub(crate) fn new(const_eval_limit: Limit, can_access_statics: bool) -> Self { </del> <ins> pub(crate) fn new( const_eval_limit: Limit, can_access_statics: bool, check_alignment: bool, ) -> Self { </ins> CompileTimeInterpreter { steps_remaining: const_eval_limit.0, stack: Vec::new(), can_access_statics, <ins> check_alignment, </ins> } } }

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
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. fn main() { let mut x = &[1, 2, 3, 4]; let mut result = vec!(); loop { x = match x { [1, n, 3, ..rest] => { result.push(n); rest } [n, ..rest] => { result.push(n); rest } [] => break } } assert!(result.as_slice() == [2, 4]); } </ins>

Discussion:
It looks like introduced a regression. The following used to work: but now generates the following error:
Yeah, sorry about that! There's already a fix for this in
I am also now seeing spurious 'non-exhaustive patterns' errors when attempting to match struct variants of an imported enum type. For example, here is a simplification of some code in : The error is:
Oh dear. Looks like it only fails when the enum is defined in a different crate as this works: I'll take a look!
Please add an appropriate test for this case... Niko
I a test for the cross-crate case in . There are already quite a few existing tests for local variants.
On Sun, Jun 22, 2014 at 07:43:54AM -0700, Jakub Wieczorek wrote: great
Change:
] [[package]] <ins> name = "lld-wrapper" version = "0.1.0" [[package]] </ins> name = "lock_api" version = "0.4.1" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Checked that on target, found duplicates in versions: and <strikeno duplicates</strike2 duplicates (<strikeonly</strike, ) in stable , (bisecting is kinda slow on my connection) there 3 copies of that executable, that gives ~ 187mb label +regression-from-stable-to-beta
Can be found in:
I think they were in and . I believe is also a copy of .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
claim
Sorry, I only came across this issue just now. The copies are there for a reason, see linked issues. Multiple things to consider: The files in the directory are only used with the unstable option. So they could be removed for beta and stable. They can be replaced with small Rust executables which just exec and respectively. I will be working on that for nightly.
Change:
use rustc_middle::ty::tls; use rustc_parse::validate_attr; #[cfg(parallel_compiler)] <del> use rustc_query_impl::QueryCtxt; </del> <ins> use rustc_query_impl::{QueryContext, QueryCtxt}; </ins> use rustc_session as session; use rustc_session::config::CheckCfg; use rustc_session::config::{self, CrateType};

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. --code from glacier <!-- 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. --: NOTE this is the alt master rustc, installed via <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This features a parallel-compiler-only bug. It is a variant of It is ultimately a blocker for and might be a blocker for but itself does not need to be fixed any time soon.
Remark from
This is not a problem with the implementation logic of the deadlock handler, but a very hard-to-trace thread scheduling vulnerability. If we add the following non-functional statement in of the function, this problem will disappear. Get rid of in deadlock handler can fix this. I just submited a to fix a set of ui test failures, including this issue.
Change:
) -> Option<()> { let span = source_info.span; <ins> // #66397: Don't try to eval into large places as that can cause an OOM if place_layout.size >= Size::from_bytes(MAX_ALLOC_LIMIT) { return None; } </ins> let overflow_check = self.tcx.sess.overflow_checks(); // Perform any special handling for specific Rvalue types.

Discussion:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.
Change:
use syntax; use syntax::ast; use syntax::ast_util; <ins> use syntax::attr; </ins> use syntax::attr::AttributeMethods; use std;

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:
err.emit(); return; } <ins> file_note.map(|note| err.note(note)); </ins> if let Some(s) = label { // If it has a custom `#[rustc_on_unimplemented]` // error message, let's display it as the label!

Discussion:
Type errors (and others) use and similar to write types that are too long to disk, so the cli output is easier to read. Trait bound errors do not do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I created . What was not visible in the tweet but that you will see when you build the repo, is that the types in the error notes are even longer. That's a shame because hidden in that noise the compiler gives the solution to the error (pin).
You can just create a gist with the error generating logic line highlighted. Much more helpful?
I can give more context too. I was implementing a K8s operator using . I start by creating a and then running it with . This returns a . That stream yields an item every time the reconcile loops reconciles an item or returns an error. For testing, I iterate over the stream to check that it reconciles items the way I expect. . The solution is to pin the stream returned by .
how would i go about solving this? claim
you can look at how we do it here You have to do the same thing but at the very least in the places we print out types to string here:
You also need to ensure that the type-shortening is conditional, based on whether the user wants verbose output or not (similar to the existing logic for type errors).
already checks whether is enabled or not before shortening.
into: by the looks: is the same as and i can call the method on it, but in the formatting (that returns a tuple) im not sure how to call those functions (as t is a string, and calling the function returns a string and pathbuf. in the closure should i just ignore ? or is that a bad approach?
Change:
if !candidate.needs_infer() { debug!(?pred, ?candidate, "insert_candidate_cache global"); // This may overwrite the cache with the same value. <del> tcx.selection_cache.insert(param_env.and(pred), dep_node, candidate); </del> <ins> tcx.selection_cache.insert((param_env, pred), dep_node, candidate); </ins> return; } } } debug!(?pred, ?candidate, "insert_candidate_cache local"); <del> self.infcx.selection_cache.insert(param_env.and(pred), dep_node, candidate); </del> <ins> self.infcx.selection_cache.insert((param_env, pred), dep_node, candidate); </ins> } /// Matches a predicate against the bounds of its self type.

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. --code from <!-- 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. --: This crashes nightly, beta and stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
<ins> use std::convert::TryFrom; pub fn test_usage(p: ()) { SmallCString::try_from(p).map(|cstr| cstr); //~^ ERROR: type annotations needed } pub struct SmallCString<const N: usize> {} impl<const N: usize> TryFrom<()> for SmallCString<N> { type Error = (); fn try_from(path: ()) -> Result<Self, Self::Error> { unimplemented!(); } } 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. --
Removing seems to fix it.
Reduced, with no nightly features (): Output on stable and beta: label regression-from-stable-to-nightly
bisection cc: searched nightlies: from nightly-2022-01-01 to nightly-2022-06-20 regressed nightly: nightly-2022-06-09 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
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Another snippet from
Change:
ty::ParamEnv::reveal_all(), alias_ty.to_ty(tcx), ); <ins> debug!("Resolved {:?} -> {resolved}", alias_ty.to_ty(tcx)); </ins> ty::ExistentialPredicate::Projection(ty::ExistentialProjection { def_id: assoc_ty.def_id, args: ty::ExistentialTraitRef::erase_self_ty(tcx, super_trait_ref).args,

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))', 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
Rust has two main types of strings: `&str` and `String`. <del> # &str </del> <ins> # `&str` </ins> The first kind is a `&str`. This is pronounced a 'string slice'. String literals are of the type `&str`:

Discussion:
The distinguishes between and but makes no mention of a third type people will come across: . is defined as the type which you refer to? Perhaps define as the type and mention that in most cases it must be borrowed... This honestly threw me the first time I saw it. I thought, "what is 's only and ...". : Error:
Note: is an unsized type, and is simply a pointer to the unsized type (like or ). But I agree that the docs could be clearer.
The error messages can be quite unfriendly for new users. I recently saw someone attempt: The error: Doesn't mean much to a new user. What does that mean to users? Is there a valid reason to ever use in code? The doc says So it's not a valid type? But the error message you gave me said "for the type " ... If it's not valid why doesn't the compiler say so in the error message above, instead of complaining that it's unsized?
Today, this is the string chapter of the book.
Change:
let pat_node = if pats.is_empty() { ast::pat_ident( <del> ast::bind_by_implicit_ref, </del> <ins> ast::bind_by_ref(ast::m_imm), </ins> cx.path(span, ~[v_name]), None )

Discussion:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here
Change:
llvm_profile_generate: matches.opt_present("llvm-profile-generate"), llvm_bolt_profile_generate: matches.opt_present("llvm-bolt-profile-generate"), llvm_bolt_profile_use: matches.opt_str("llvm-bolt-profile-use"), <ins> free_args, </ins> } } }

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
(sym::repr, Normal, template!(List: "C, packed, ..."), Ungated), (sym::path, Normal, template!(NameValueStr: "file"), Ungated), (sym::automatically_derived, Normal, template!(Word), Ungated), <del> (sym::no_mangle, Normal, template!(Word), Ungated), </del> <ins> (sym::no_mangle, Whitelisted, template!(Word), Ungated), </ins> (sym::no_link, Normal, template!(Word), Ungated), (sym::derive, Normal, template!(List: "Trait1, Trait2, ..."), Ungated), (

Discussion:
Steps to reproduce: 1) make an new crate, set crate type to 2) put a simple function in : 3) build with 4) copy the command line used from above step, and run it as-is example: As you can see, the first time in step 3) has no warnings, however, step 4) cause complains is unused, which isn't true. Step 4) can be replaced by: modify , so that it cause rebuild run again rustc 1.35.0-nightly ( 2019-04-16)
I have same error on today's nightly too
Same for me
I see the same warning text during a build for crate type “staticlib” using nightly 1.36.0 commit 2019-04-18
I will bisect this and then pass the baton to to fix this.
Bisection claims , (). cc
My guess is that should be a attribute? It was declared twice before and the variant got removed.
Also our scheme to track unused attributes does not work the incremental compilation, which is probably why it only happens with that.
cc
A fix is up. I this still nightly only or do we need to backport?
Seems to be nightly-only still
I get this with regular on a crate type with nightly
can you try with the latest nightly? This was only closed yesterday, so today's nightly should contain the fix.
My case () is no longer reproducible on 2019-05-21 nightly.
I no longer see the ~error~ warning with .
Yep it seems it's fixed. sorry I missed that it was merged yesterday. thanks!
Change:
matches!(self.inner, Active) } <del> pub fn is_resrved(self) -> bool { </del> <ins> pub fn is_reserved(self) -> bool { </ins> matches!(self.inner, Reserved { .. }) }

Discussion:
You can't create pure closures right now. This is sometimes helpful in writing functions that operate on const data. I think this will just be a matter of adjusting typeck to determine purity from the expected type.

As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .
Change:
<ins> // Copyright 2015 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. use std::mem; pub struct X([u8]); fn _f(x: &X) -> usize { match *x { X(ref x) =>  { x.len() } } } fn main() { let b: &[u8] = &[11; 42]; let v: &X = unsafe { mem::transmute(b) }; assert_eq!(_f(v), 42); } </ins>

Discussion:
Fedora 21 x86_64, rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23). I hit an assertion when compiling cuviper/rust-git-fs I haven't tried to reduce it yet. Stack trace from coredumpctl:
I narrowed this down to my , where a is indexed by a . I can reproduce the crash with this smaller example: If I convert to a first, then all is fine.
Another example is:
Does not seem to affect beta or nightly. Marking as E-needstest
I'll add regression tests for these examples right now