jiebi/CodeConvo huggingface dataset:
Change:
} /// Sets the platform-specific value of errno <del> #[cfg(any(target_os = "solaris", target_os = "fuchsia"))] // only needed for readdir so far </del> <ins> #[cfg(all(not(target_os = "linux"), not(target_os = "dragonfly")))] // needed for readdir and syscall! </ins> pub fn set_errno(e: i32) { unsafe { *errno_location() = e as c_int

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.
Change:
self.builder.cp_r(src.as_ref(), &dest); } <ins> pub(crate) fn add_bulk_dir(&mut self, src: impl AsRef<Path>, dest: impl AsRef<Path>) { self.bulk_dirs.push(dest.as_ref().to_path_buf()); self.add_dir(src, dest); } </ins> pub(crate) fn generate(self) -> GeneratedTarball { let mut component_name = self.component.clone(); if self.is_preview {

Discussion:
CC On today's git () seems to get stuck if you are building docs. In : will get stuck at: The underlying command is: Adding this to the config seems to work around the hang: Thanks!
How long did you let the command run before killing it? I remember installing the docs taking a long time last time I did it.
I left it for half an hour or so IIRC. I'll run it for longer and see if it goes away. How long do you think it should take to install on a modern SSD?
I don't remember exactly how long it takes, but it doesn't depend on the speed of the disk. is just really inefficient. You can see if it's actually hanging by checking the contents of this command while it's installing:
The log file is empty, but I can see new files appearing on the disk (using and ) so progress must be occurring. Slowly.
It's been about 40 minutes now. It seems to be adding files to is that right?
So it's just very slow.
I took a look into this. The main issue is that the generated is very inefficient; it takes about 5 minutes to copy 2500 files (there are more than 2500, but I got bored and cancelled it). what do you think about rewriting this inner loop in Rust so it's not launching so many external processes?
This issue is compounded on macOS, where it seems to be even more inefficient to launch lots of processes from a shell. Sorry I don't have timings, but it takes tens of minutes at least for this step [edit: over an hour]; long enough that I would expect most users who are trying to build our software from source in macOS (it's Zcash, which installs a pinned version of Rust in order to build) are likely to think it's hanging and give up.
I think the problem may largely be that the generated for rust-docs component (at least) is a file: list instead of using the directory: command; directory commands should be much more efficient. This change may be a recent(ish) regression; I suspect that fixing that is likely the right solution here.
Oops I forgot to link back here: we discussed this briefly and it was difficult to do in a cross-platform way.
We solved our problem for Zcash by just not installing rust-docs (passing to ).

This reduced our total build time on macOS ! Obviously it doesn't solve the underlying issue.
FYI, addresses this (not the underlying cause of the inefficiency but the majority of its extent).
I bisected the underlying issue to “bootstrap: convert rust-docs to use Tarball” (). Before this commit, rust-docs installs in half a second, and is 1 line: After this commit, rust-docs installs in some twenty minutes, and is lines:
Proposed fix in . (We should also do the optimization in rust-lang/rust-installer of course.)
Change:
Node::ImplItem(hir::ImplItem { kind: hir::ImplItemKind::Fn(header, ..), .. }) => Some(header), <ins> Node::TraitItem(hir::TraitItem { kind: hir::TraitItemKind::Fn(header, ..), .. }) => Some(header), </ins> // Closures are RustCall, but they tuple their arguments, so shouldn't be checked Node::Expr(hir::Expr { kind: hir::ExprKind::Closure(..), .. }) => None, node => bug!("Item being checked wasn't a function/closure: {:?}", node),

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. --: <!-- 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 --
This crashes on master/nightly but not on
This is an overlooked case for , I can add it to the type-checking claim
I couldn't find a regression-from-beta-to-nightly label so using label +regression-from-stable-to-nightly
How did this not get caught by CI?
Assigning and removing as in the prioritization working group.
How did this not get caught by CI? I guess the original code (which triggers the ice) got changed. I found this by running todays rustc on the testcases from a couple of releases/years ago. :)
Yep, the test case was changed as part of the original PR. I didn't think to add the trait case to the new test, I've fixed that oversight (And one or two other possible cases) in the fix.
Regression is on beta now.
Change:
<ins> // check-pass #![feature(generic_const_exprs)] #![allow(incomplete_features)] // issue #107899 // We end up relating `Const(ty: size_of<?0>, kind: Value(Branch([])))` with // `Const(ty: size_of<T>, kind: Value(Branch([])))` which if you were to `==` // the `ty` fields would return `false` and ICE. This test checks that we use // actual semantic equality that takes into account aliases and infer vars. use std::mem::size_of; trait X<T> { fn f(self); fn g(self); } struct Y; impl<T> X<T> for Y where [(); size_of::<T>()]: Sized, { fn f(self) { self.g(); } fn g(self) {} } 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. --<!-- 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</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
) .unwrap(); let mut hidden_type = infcx.resolve_vars_if_possible(decl.hidden_type); <del> // Check that RPITs are only constrained in their outermost // function, otherwise report a mismatched types error. if let OpaqueTyOrigin::FnReturn(parent) | OpaqueTyOrigin::AsyncFn(parent) = infcx.opaque_ty_origin_unchecked(opaque_type_key.def_id, hidden_type.span) && parent.to_def_id() != body.source.def_id() { infcx .report_mismatched_types( &ObligationCause::misc( hidden_type.span, infcx.tcx.hir().local_def_id_to_hir_id( body.source.def_id().expect_local(), ), ), infcx.tcx.mk_opaque(opaque_type_key.def_id.to_def_id(), opaque_type_key.substs), hidden_type.ty, ty::error::TypeError::Mismatch, ) .emit(); } </del> trace!( "finalized opaque type {:?} to {:#?}", opaque_type_key,

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
/// Extracts `--extern CRATE=PATH` arguments from `matches` and /// returns a map mapping crate names to their paths or else an /// error message. <ins> /// Also handles `--extern-private` which for the purposes of rustdoc /// we can treat as `--extern` </ins> // FIXME(eddyb) This shouldn't be duplicated with `rustc::session`. fn parse_externs(matches: &getopts::Matches) -> Result<Externs, String> { let mut externs: BTreeMap<_, ExternEntry> = BTreeMap::new(); <del> for arg in &matches.opt_strs("extern") { </del> <ins> for arg in matches.opt_strs("extern").iter().chain(matches.opt_strs("extern-private").iter()) { </ins> let mut parts = arg.splitn(2, '='); let name = parts.next().ok_or("--extern value must not be empty".to_string())?; let location = parts.next().map(|s| s.to_string());

Discussion:
/cc
So the explosion is that somehow the crate index in the is broken, or at least not entirely right. Interestingly if you add to the then it no longer ICEs (but has the same ) Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both and prevent the iCE)
Maybe it's linked to ? If so, it's not in rustdoc but below.
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the instance. Since was made optional, and crate names are automatically part of the global scope, people stopped necessarily telling the compiler about the crates in their code. If a comment references a path in this manner, but the code itself doesn't, then the resolver frozen into the doesn't have that crate's metadata loaded into it. When we then ask the resolver to resolve a new path (e.g. ) it goes ahead and loads the crate into a different instance of the than will be used when we then try and use the later. It feels like the moment a is d it should also be locked so that it can never be modified again. It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, , I feel this is probably either a bug in how is handling the resolver, or else a change in how the resolver behaves which either needs fixing, or changing in to cope.
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: and instead try and find a resolver as part of the closure here: Of course, it looks like a has an immutable copy of the resolver's outputs, and no access to the resolver itself, urgh, and we have no easy way to inject changes into the context at this point.
I wonder why that type can be cloned in the first place...

I found an ICE when trying to document the [spirit-log][1] crate on the latest . Skimming through the backtrace, it looks like accessed an invalid index while traversing links within . Steps to reproduce: [1]:
Taking a look.
Actually, it's failing outside of rustdoc so I prefer to let someone else handle it. cc
I think this might be a bug (or at least mismatch between how uses the resolver infrastructure and how it's meant to work). See my comment here:
Change:
<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/issue-46511.rs:5:35 | LL |     _a: [u8; std::mem::size_of::<&'a mut u8>()] |                                   ^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = help: add `#![feature(generic_const_exprs)]` to the crate attributes to enable error[E0392]: parameter `'a` is never used --> $DIR/issue-46511.rs:3:12 | LL | struct Foo<'a> |            ^^ unused parameter | = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData` error: aborting due to 2 previous errors Some errors have detailed explanations: E0392, E0658. For more information about an error, try `rustc --explain E0392`. </ins>

Discussion:
The following simpl file causes rustc to panic when compiling:
Oh, removing the lifetime parameter in the type passed to size_of does not panic:
Reproduces with the NLL borrow checker (crashes in ). cc
Triage: This is no longer ICE with the latest nightly ( forbid the case):
Change:
&b.item_def_id, ))) } else { <del> let ty = relation.relate(&a.ty, &b.ty)?; let substs = relation.relate(&a.substs, &b.substs)?; </del> <ins> let ty = relation.relate_with_variance(ty::Invariant, &a.ty, &b.ty)?; let substs = relation.relate_with_variance(ty::Invariant, &a.substs, &b.substs)?; </ins> Ok(ty::ExistentialProjection { item_def_id: a.item_def_id, substs, ty }) } }

Discussion:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).
Change:
debug = false debug-assertions = false <ins> [profile.release.package.compiler_builtins] # For compiler-builtins we always use a high number of codegen units. # The goal here is to place every single intrinsic into its own object # file to avoid symbol clashes with the system libgcc if possible. Note # that this number doesn't actually produce this many object files, we # just don't create more than this number of object files. # # It's a bit of a bummer that we have to pass this here, unfortunately. # Ideally this would be specified through an env var to Cargo so Cargo # knows how many CGUs are for this specific crate, but for now # per-crate configuration isn't specifiable in the environment. codegen-units = 10000 </ins> # We want the RLS to use the version of Cargo that we've got vendored in this # repository to ensure that the same exact version of Cargo is used by both the # RLS and the Cargo binary itself. The RLS depends on Cargo as a git repository

Discussion:
I'm currently doing some benchmarks and I've seen that is taking a really long time to calculate on wasm. Turns out that none of the helper functions it uses are inlined at all, so it does a ton of unnecessary calls and misses a lot of potential optimizations: The same is probably true for the Float trait.
It seems like initially had a lot more inline annotations but removed them later on. That may have regressed the performance on wasm, but I'm not entirely sure. This makes me wonder if compiler-builtins is even compiled with LTO at all as it supposedly is meant to be?!
Looks like this is indeed a regression that started with Rust 1.44, which switched from compiler-builtins 0.1.25 to 0.1.27, which is where this PR is part of. These are the instructions in 1.43: cc
There's been a few various changes around codegen units handling and compiler-builtins recently, and it looks like this is caused by compiling this crate with . The compiler but with only one CGU.
Ok I've transferred this to the rust-lang/rust repository since this isn't a bug with compiler-builtins itself I believe but rather how we build compiler-builtins. I believe this is an accidental regression from because only part of the compiler knows that compiler-builtins is built with more than one CGU, the rest of the compiler thinks it's one CGU (respecting CLI flags). I'll be opening a PR shortly to fix this.
Assigning as and removing .
Change:
// Ensure that if ~T is cast to ~Trait, then T : Trait push_cast_obligation(fcx, cast_expr, object_trait, referent_ty); <del> check_object_safety(fcx.tcx(), object_trait, source_expr.span); </del> <ins> check_object_safety(fcx.tcx(), &object_trait.principal, source_expr.span); </ins> } (&ty::ty_rptr(referent_region, ty::mt { ty: referent_ty,

Discussion:
The following code either aborts or segfaults for me, depending on if I'm in gdb or not, on Linux: With optimizations, becomes Which means we're doing something very bad when translating this code.
Still reducing...
FWIW, I can confirm that behaviour on Windows.
cc me
Reduced: And that makes it clear the issue is not broken codegen, but rather that is mistakenly treated as object-safe (while it inherits from the non-object-safe ).
nice. cc
P-backcompat-lang, 1.0.
Hint: iterate with
takes/creates s but needs a . I'm not sure how to make these agree.
checkobjectsafety should use to enumerate the trait_ref, I think. Annoyingly this does require a right now (harder to fix than you might think).
On I get , which is an unwrap in in the supertraits iterator.
Change:
<del> Subproject commit cba558df777a045b5657d56c29944e9e8fd3a776 </del> <ins> Subproject commit 522c3e3d9c097b53ede7682cc28544b461597b20 </ins>

Discussion:
Functions using the calling convention return values in one of three ways (): 32 bits or smaller: in register 33-64 bits: in and registers 65 bits or larger: by a pointer passed into the function from the calling code In the third case, the pointer is not considered to be part of the argument list size for the purposes of the name mangling suffix. For example: However, if we try to link to this function from Rust: Then we get a linker error because the argument list size is incorrectly calculated as instead of : Thanks to for the !
Does this only affect or does it also affect on 32-bit Windows? Probably not the place to ask, but: and on both follow the x64 default calling convention (which functionally extends the convention), as it is the default calling convention for the platform, right?
I think on 32-bit Windows would be the which doesn't append the parameter size in bytes to the decorated name so there should be no issue there. I believe the affected calling conventions are , and . That should be the case, yes. AFAIK, the only supported calling conventions on x8664-pc-windows-msvc are and .
Probably need to update LLVM here: I imagine something like this in the loop would work:
Based on the LLVM Lang Ref, it read to me like just the presence of the attribute would be sufficient to indicate the parameter size should not be included. Therefore my patch looks like this: Does that seem reasonable to you or do you think we should include the additional check for ?
Ah, you're right, just checking for sret should suffice.