jiebi/CodeConvo huggingface dataset:
Change:
} fn check_for_opaque_ty(&mut self, sp: Span, ty: Ty<'tcx>) -> bool { <del> struct ProhibitOpaqueTypes<'tcx> { </del> <ins> struct ProhibitOpaqueTypes<'a, 'tcx> { cx: &'a LateContext<'a, 'tcx>, </ins> ty: Option<Ty<'tcx>>, }; <del> impl<'tcx> ty::fold::TypeVisitor<'tcx> for ProhibitOpaqueTypes<'tcx> { </del> <ins> impl<'a, 'tcx> ty::fold::TypeVisitor<'tcx> for ProhibitOpaqueTypes<'a, 'tcx> { </ins> fn visit_ty(&mut self, ty: Ty<'tcx>) -> bool { <del> if let ty::Opaque(..) = ty.kind { self.ty = Some(ty); true } else { ty.super_visit_with(self) </del> <ins> match ty.kind { ty::Opaque(..) => { self.ty = Some(ty); true } // Consider opaque types within projections FFI-safe if they do not normalize // to more opaque types. ty::Projection(..) => { let ty = self.cx.tcx.normalize_erasing_regions(self.cx.param_env, ty); // If `ty` is a opaque type directly then `super_visit_with` won't invoke // this function again. if ty.has_opaque_types() { self.visit_ty(ty) } else { false } } _ => ty.super_visit_with(self), </ins> } } } <del> let mut visitor = ProhibitOpaqueTypes { ty: None }; </del> <ins> let mut visitor = ProhibitOpaqueTypes { cx: self.cx, ty: None }; </ins> ty.visit_with(&mut visitor); if let Some(ty) = visitor.ty { self.emit_ffi_unsafe_type_lint(ty, sp, "opaque types have no C equivalent", None);

Discussion:
cc Gives the following incorrect warning:
I'm not sure if this is incorrect - I think this is what I'd expect. In the declaration of , we don't know what concrete type is - if it were , then we could normalize to - but we don't know? Maybe I'm missing something.
Hmm, that might be true. I definitely think that the following should not lint here (with bound to u32)
I agree that seems like it should be fine. So, this happens because of this call: It makes sense that we want to lint on opaque types on extern declarations, it's unclear whether we would want to allow projections which contain opaque types - this would solve the case you've shown here, but could be used to "sneak" opaque types by the lint (in , the projection normalizes to an opaque type; it's hard to detect because the normalization goes further and resolves it to so we can't tell that it was an opaque type) - I have a build with this locally. Any thoughts on whether we should change the behavior here? cc
Hm, I think it might be worth it to normalize using here, which should not normalize the first case and your example while fixing the second one if I am not mistaken.
Long ago I filed where we also concluded Reveal::UserFacing is the right behavior for normalization in this lint. The current behavior comes from cc
I'll put up a PR with my experiments from last night later in that case.
Change:
ShouldRun { builder, paths: BTreeSet::new(), <del> is_really_default: true, // by default no additional conditions </del> <ins> is_really_default: ReallyDefault::Bool(true), // by default no additional conditions </ins> } } pub fn default_condition(mut self, cond: bool) -> Self { <del> self.is_really_default = cond; </del> <ins> self.is_really_default = ReallyDefault::Bool(cond); self } pub fn lazy_default_condition(mut self, lazy_cond: Box<dyn Fn() -> bool + 'a>) -> Self { self.is_really_default = ReallyDefault::Lazy(Lazy::new(lazy_cond)); </ins> self } <ins> pub fn is_really_default(&self) -> bool { match &self.is_really_default { ReallyDefault::Bool(val) => *val, ReallyDefault::Lazy(lazy) => *lazy.deref(), } } </ins> /// Indicates it should run if the command-line selects the given crate or /// any of its (local) dependencies. ///

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
<ins> // check-pass const SZ: usize = 64_000_000; type BigDrop = [String; SZ]; fn f(_dropme: BigDrop) {} fn f2(_moveme: BigDrop) -> String { let [a, ..] = _moveme; a } fn main() { f(std::array::from_fn(|_| String::new())); f2(std::array::from_fn(|_| String::new())); } </ins>

Discussion:
Attempting to compile this code causes extremely large memory usage by rustc. By experimentation, the important features of the code are: large , the element type needs to have drop glue, and the drop can't be skipped with or some other mechanism. It also must be a program, not a library function. The problematic compiler invocation: . I expected to see this happen: The compiler memory usage shouldn't run away due to large ; in fact the compiler memory usage should be almost entirely independent of for this program. Instead, this happened: When is large, uses a lot of memory and takes a long time. I have not successfully compiled the above program with the given of 64M. I repro'd this on , , and finally: (I did not capture a compiler backtrace.) I surmise that there's a correlation between and compiler behavior but I haven't explored it beyond verifying a small doesn't repro the bad behavior. I thought perhaps this program tries to use the stack for the slice-array cast, and somehow the compiler is getting stuck on such a large stack frame. Thankfully, this is ruled out by checking that does indeed do the slice-array cast entirely using pointers. So the compiler shouldn't "see" how big the array is; it's behind a pointer. Appending to bypasses the issue, so it appears to be drop glue for the box which causes the problem. I don't see a particular reason why the drop glue for this type should be problematic; it should be no different than dropping the initialized part of a large . </p</details
is what shows up in logging right before hanging + memory explodes seems to be the culprit. ...
Change:
let predicate = predicate.fold_with(&mut BottomUpFolder { tcx, ty_op: |ty| match ty.kind() { <del> ty::Projection(projection_ty) => infcx.infer_projection( self.param_env, *projection_ty, traits::ObligationCause::misc(self.value_span, self.body_id), 0, &mut self.obligations, ), </del> <ins> ty::Projection(projection_ty) if !projection_ty.has_escaping_bound_vars() => { infcx.infer_projection( self.param_env, *projection_ty, traits::ObligationCause::misc(self.value_span, self.body_id), 0, &mut self.obligations, ) } </ins> _ => ty, }, lt_op: |lt| lt,

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</detailsThanks for investigating into this issue! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
... I found that I forget to impl and for bool. Even if I do: The issue still exists...
claim

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I was experimenting with Bevy, and suddenly found has stopped me to show errors. It turned out that paniced on this function: I a commit with exact state of my project (it's pretty small ATM) where the compiler pianics <!-- 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
Thanks for the code. Would be great if someone could take a stab at minimizing it. label +E-needs-mcve I may come back and attempt to myself
I've managed to get it to this point.
Here's a version with the bevy calls minimized as well
epic! label -E-needs-mcve glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Error: Parsing glacier command in failed: ...' glacier :' ''... Please let know if you're having trouble with this bot.
Oh, can the glacier command only be used by repository members?
Change:
configured_targets.append(target) for target in configured_targets: targets[target] = sections['target'][:] <del> targets[target][0] = targets[target][0].replace("x86_64-unknown-linux-gnu", target) </del> <ins> targets[target][0] = targets[target][0].replace("x86_64-unknown-linux-gnu", "'{}'".format(target)) </ins> def is_number(value):

Discussion:
When running  to cross-compile for a Cortex M target, a few issues arise with the fact that the target has a in the name. There are two issues that I noticed: generates an invalid — this is easy to fix with a change to the example file. looks for compiler flags in difficult-to-name variables — this is harder to fix, but can be (painfully) worked around. To illustrate issue 1, I tried this code: I expected to see this happen: compilation should get pretty far (I'm eliding some of the things that would make it actually succeed, for brevity, but successfully building stage0 rustc is expected at least) Instead, this happened: compilation fails after one minute with the error: This is because the generated contains this line (note the problematic period): I believe this comes from , where we unconditionally replace in the . If is updated to put quotes around its target architecture, this issue is solved: Issue 2 takes more effort to reproduce, and is technically not a bug in rustc, but in the crate. Or maybe it's not a bug at all, but it's pretty darn unfortunate. In particular, the intended way to specify (and friends) for is to write to the environment variable , or . The problem: most shells do not allow users to export environment variables that contain the character: If I fix issue 1 as described above, and use the workaround to get around issue 2, I am able to build a target that has a period in it. This was tested with current top of tree (commit ) but does not appear to be a recent regression. I see the same behavior when my host is either or , which is unsurprising. I think it makes sense to split issues 1 and 2 into separate bug reports (issue 2 being reported on the crate) -- but wanted to get this out there first to simply reflect that targets with dots are currently difficult to build for. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the bug report!

I think it's unlikely we will do anything about 2 in rust-lang/rust itself (having a target with a dot and having to set CFLAGS seems rare), but 1 is definitely a bug we should fix. Mentoring instructions: in add quotes around the we're replacing the default with. label +A-rustbuild +E-easy +E-mentor +E-help-wanted
claim
Change:
EncodeContext::encode_info_for_foreign_item, (def_id, ni)); } <del> fn visit_variant(&mut self, v: &'tcx hir::Variant, g: &'tcx hir::Generics, id: hir::HirId) { intravisit::walk_variant(self, v, g, id); if let Some(ref discr) = v.disr_expr { let def_id = self.tcx.hir().local_def_id(discr.hir_id); self.record(def_id, EncodeContext::encode_info_for_anon_const, def_id); } } </del> fn visit_generics(&mut self, generics: &'tcx hir::Generics) { intravisit::walk_generics(self, generics); self.encode_info_for_generics(generics); } <del> fn visit_ty(&mut self, ty: &'tcx hir::Ty) { intravisit::walk_ty(self, ty); self.encode_info_for_ty(ty); } </del> fn visit_macro_def(&mut self, macro_def: &'tcx hir::MacroDef) { let def_id = self.tcx.hir().local_def_id(macro_def.hir_id); self.record(def_id, EncodeContext::encode_info_for_macro_def, macro_def);

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
EncodeContext::encode_info_for_foreign_item, (def_id, ni)); } <del> fn visit_variant(&mut self, v: &'tcx hir::Variant, g: &'tcx hir::Generics, id: hir::HirId) { intravisit::walk_variant(self, v, g, id); if let Some(ref discr) = v.disr_expr { let def_id = self.tcx.hir().local_def_id(discr.hir_id); self.record(def_id, EncodeContext::encode_info_for_anon_const, def_id); } } </del> fn visit_generics(&mut self, generics: &'tcx hir::Generics) { intravisit::walk_generics(self, generics); self.encode_info_for_generics(generics); } <del> fn visit_ty(&mut self, ty: &'tcx hir::Ty) { intravisit::walk_ty(self, ty); self.encode_info_for_ty(ty); } </del> fn visit_macro_def(&mut self, macro_def: &'tcx hir::MacroDef) { let def_id = self.tcx.hir().local_def_id(macro_def.hir_id); self.record(def_id, EncodeContext::encode_info_for_macro_def, macro_def);

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
}; self.write_value(valty, dest)?; } <ins> // slices and trait objects to thin pointers (dropping the metadata) </ins> (Value::ByValPair(data, _), false) => { let valty = ValTy { value: Value::ByVal(data),

Discussion:
At This is used by is_null() Backtrace: cc solson/miri
Minimal repro:
Change:
S 2015-08-11 1af31d4 <del> bitrig-x86_64 0000000000000000000000000000000000000000 freebsd-i386 0000000000000000000000000000000000000000 freebsd-x86_64 0000000000000000000000000000000000000000 </del> <ins> bitrig-x86_64 739e0635cd5a1b3635f1457aae3ef6390ea9a7a8 freebsd-i386 3cd4a44fb97b3135be3d1b760bea604a381e85dc freebsd-x86_64 de1f36592bac0eeb90c049a8421246652c511b9e </ins> linux-i386 e2553bf399cd134a08ef3511a0a6ab0d7a667216 linux-x86_64 7df8ba9dec63ec77b857066109d4b6250f3d222f macos-i386 29750870c82a0347f8b8b735a4e2e0da26f5098d

Discussion:
This issue is for adding the snapshots.
Snapshots inbound. See PR
Could you please look into taking care of NetBSD as well?
I've got a NetBSD builder set up on my VM host already but I've been unable to build it from source just yet. I've been using my cross-bootstrap scripts to get a rustc that runs on NetBSD. Just a couple issues left I think, but I'm busy with lots of things right now. It might be a little while, but I'm hoping to have it online ASAP.
great, thanks for the update!
Change:
"flate2 0.2.19 (registry+https://github.com/rust-lang/crates.io-index)", "kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", <del> "tar 0.4.12 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "tar 0.4.13 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "walkdir 1.0.7 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", "xz2 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
I got in a project of mine for recent nightlies which I think are releated to the rustification of rust-installer but I'm not 100% certain: does this sound familiar to you?
Oh looks like and are all related to this as well.
Ah, yes, backslashes in the manifest are an easily understood problem. Executable is harder. At least I left a note about that . :) Since Windows doesn't really have such flags, I suspect it must have worked on some MSYS tricks with ACLs before. Maybe we should make a special case for this when writing the tarball, like writing known-executable file names with manually-tweaked metadata?
Yeah I think we'll probably just want to special case everything going into the tarballs and manually set the metadata for the various bits and pieces. I'm... not entirely sure how this worked with MSYS, but presumably there's some weird translation layer which we're not aware of and isn't surfaced through winapi things...
OK, so should fix up the manifests at least. Researching the file modes, I first wondered whether the crate should read the advanced ACLs for , as right now it just . But it looks like all created files have "execute" privileges anyway -- e.g. even includes . You can remove that with in MSYS/Cygwin/etc., but it appears atypical for a file not_ to be executable. The good news is that also doesn't care about execute when unpacking on Windows, just . The rest will follow the defaults of , still with executable ACLs. So I think the permissions created by rustup will be fine, but I guess if one manually unpacks with MSYS/Cygwin tar they may get non-executable etc. The quickest hack for you would be to just change this: Step 7 : RUN /tmp/rust-mingw-nightly-i686-pc-windows- --prefix= ... to invoke instead, which doesn't care about execute privileges. :)
Ah yeah I don't think there's a great way to flag a file on Windows as executable/not-executable, I'm basically just thinking that we have a whitelist of files/patterns that will get listed as executable in the tarball (as the tarball stores unix modes) and we'd just follow that.
Change:
<ins> // Copyright 2016 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. #![crate_type = "rustc-macro"] #![feature(rustc_macro)] #![feature(rustc_macro_lib)] extern crate rustc_macro; use rustc_macro::TokenStream; #[rustc_macro_derive(A)] pub fn derive(input: TokenStream) -> TokenStream { let input = input.to_string(); assert!(input.contains("struct A;")); "struct B;".parse().unwrap() } </ins>

Discussion:
Noticed it causing issues with cargo as it uses and then parses the files as part of the fingerprinting process. It seems every instance of macro generated code (e.g. via serde_derive) creates a entry into this file which when cargo tries to look up it can't find. Cargo issue:
Added this to the macros 1.1 tracking issue (I consider this a blocker for stabilization)
Change:
&& let Some(node) = tcx.hir().get_if_local(def_id) && let Some(sig) = node.fn_sig() { <del> sig.decl.inputs.len() + sig.decl.implicit_self.has_implicit_self() as usize </del> <ins> sig.decl.inputs.len() </ins> } else { tcx.dcx().abort_if_errors(); unreachable!()

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: /home/gh- --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [typeck] type-checking [fnsig] computing function signature of --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Possibly related to , possibly somewhat related to , cc very astute assertions!
claim