jiebi/CodeConvo huggingface dataset:
Change:
CU2: *mut *mut c_void); pub fn LLVMRustThinLTOPatchDICompileUnit(M: ModuleRef, CU: *mut c_void); pub fn LLVMRustThinLTORemoveAvailableExternally(M: ModuleRef); <ins> pub fn LLVMRustLinkerNew(M: ModuleRef) -> LinkerRef; pub fn LLVMRustLinkerAdd(linker: LinkerRef, bytecode: *const c_char, bytecode_len: usize) -> bool; pub fn LLVMRustLinkerFree(linker: LinkerRef); </ins> }

Discussion:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet
Change:
<ins> error[E0084]: unsupported representation for zero-variant enum --> $DIR/issue-100631.rs:4:1 | LL | #[repr(C)] | ^^^^^^^^^^ LL | #[repr(C)] LL | enum Foo {} | -------- zero-variant enum error: aborting due to previous error For more information about this error, try `rustc --explain E0084`. </ins>

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> Subproject commit 8707ceaf040f6d87b67a002de16a8d2bc4db7a41 </del> <ins> Subproject commit b4ff403041f17957f735ad750c3241a3a428b9b7 </ins>

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:
hir_ids_and_spans.into_iter().map(|(_, _, ident_span)| ident_span).collect(); on_used_on_entry(spans, id, ln, var); } else { <del> self.report_unused(hir_ids_and_spans, ln, var); </del> <ins> self.report_unused(hir_ids_and_spans, ln, var, can_remove); </ins> } } } <ins> #[tracing::instrument(skip(self), level = "INFO")] </ins> fn report_unused( &self, hir_ids_and_spans: Vec<(HirId, Span, Span)>, ln: LiveNode, var: Variable, <ins> can_remove: bool, </ins> ) { let first_hir_id = hir_ids_and_spans[0].0;

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
<ins> error[E0015]: cannot call non-const fn `<() as Foo>::foo` in constant functions --> $DIR/const_closure-const_trait_impl-ice-113381.rs:13:22 | LL |     (const || { (()).foo() })(); |                      ^^^^^ | = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants error: aborting due to previous error For more information about this error, try `rustc --explain E0015`. </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</details
Fixed on the latest nightly, marking as E-needs-test (or, feel free to close if we have a sufficient regression test) labels: +E-needs-test
Change:
fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.build_triple()); <ins> let krate = builder.crate_paths[&run.path]; let test_kind = builder.kind.into(); </ins> <del> for krate in builder.in_tree_crates("rustc-main", Some(run.target)) { if krate.path.ends_with(&run.path) { let test_kind = builder.kind.into(); builder.ensure(CrateLibrustc { compiler, target: run.target, test_kind, krate: krate.name, }); } } </del> <ins> builder.ensure(CrateLibrustc { compiler, target: run.target, test_kind, krate }); </ins> } fn run(self, builder: &Builder<'_>) {

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
// double the length. let mut f = self.output_base_dir().join("a"); // FIXME: This is using the host architecture exe suffix, not target! <del> if self.config.target.starts_with("wasm") { </del> <ins> if self.config.target.contains("emscripten") { f = f.with_extra_extension("js"); } else if self.config.target.starts_with("wasm") { </ins> f = f.with_extra_extension("wasm"); } else if self.config.target.contains("spirv") { f = f.with_extra_extension("spv");

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
// rustfmt-edition: 2018 fn foo() -> impl async Fn() {} <ins> fn bar() -> impl for<'a> async Fn(&'a ()) {} </ins>

Discussion:
I tried : I expected to see this happen: nothing Instead, this happened: rustfmt reorders and incorrectly...
cc I imagine this blocks stabilization.
Ah, I definitely forgot to reorder these bounds after we settled the ordering.
Change:
let layout = ccx.layout_of(t); debug!("DST {} layout: {:?}", t, layout); <ins> // Returns size in bytes of all fields except the last one // (we will be recursing on the last one). fn local_prefix_bytes(variant: &ty::layout::Struct) -> u64 { let fields = variant.offset_after_field.len(); if fields > 1 { variant.offset_after_field[fields - 2].bytes() } else { 0 } } </ins> let (sized_size, sized_align) = match *layout { ty::layout::Layout::Univariant { ref variant, .. } => { <del> (variant.min_size().bytes(), variant.align.abi()) </del> <ins> (local_prefix_bytes(variant), variant.align.abi()) </ins> } _ => { bug!("size_and_align_of_dst: expcted Univariant for `{}`, found {:#?}",

Discussion:
Configure flags (I suspect is the only relevant one, though of course I recommend passing for bootstrapping): Steps to reproduce:
indicates that this was injected by (PR ); cc
I didn't fully check the validity of the rest of the code, I thought it was correct modulo initial starting data. Maybe it doesn't round up to the struct's own alignment? Resulting in a smaller size passed to jemalloc.
Stepping through a variant of the code, I'm certainly observing a discrepancy where we pass a small size to allocate and a larger size to deallocate.
Code: some data from : In particular, the input to is 128, while the at deallocation is claimed to be 136.
(note that the code I posted is not printing the actually relevant sizes, since it seems to me like our issue is with the size of the array in the , but that code is only printing the size of the itself. Whoops.) After fixing that, reports 112 for the size of the and the ; of course the actually value being allocated is an , which adds an additional pair of fields to the structure, so we end up with 112 + 16 = 128. Not sure yet where the 136 is coming from; perhaps we are adding another 8 somewhere?
On the other hand, manually breaking on (instantiated to ), and walking through it indicates that it is definitely returning 136. Here's the LLVM IR for the generated code for that routine: (I haven't yet validated where its getting 8 and 24 from in that computation, but if nothing else:
Hmm maybe we are double-counting the contribution when we calculate ?
In particular, where we recurse: that is recurring on the last field that is immediately present in the struct, causing us to add 8. But the already computed prefix size (24 in this case) actually includes_ the prefix that is in that last field, I think
Does instead of the last field work? If the intention is to find the nested-most field, that is. Although, I'm not entirely sure that would work well due to alignment. Come to think of it, is this because includes nested prefixes, and we don't want that? It should be easy enough to completely ignore the last field, instead of it'd be
yeah that sounds promising (that is, to not use at all) Update: Initial results look good, at least in terms of fixing this particular bug.
Change:
return; } <del> let mut acc = CTypesVisitorState { cache: FxHashSet::default(), base_ty: ty, recursion_depth: 0 }; </del> <ins> let mut acc = CTypesVisitorState { cache: FxHashSet::default(), base_ty: ty }; </ins> match self.check_type_for_ffi(&mut acc, ty) { FfiResult::FfiSafe => {} FfiResult::FfiPhantom(ty) => {

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
pub err: ty::type_err<'tcx> } <ins> #[derive(PartialEq, Eq)] </ins> enum ProjectionTyCandidate<'tcx> { ParamEnv(ty::PolyProjectionPredicate<'tcx>), Impl(VtableImplData<'tcx, PredicateObligation<'tcx>>),

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
if start_l == end_l { // Trace `block_l` elements from the left side. start_l = MaybeUninit::slice_as_mut_ptr(&mut offsets_l); <del> end_l = MaybeUninit::slice_as_mut_ptr(&mut offsets_l); </del> <ins> end_l = start_l; </ins> let mut elem = l; for i in 0..block_l {

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- 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<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
} } <del> pub fn solution(&self, err: &mut Diagnostic) { </del> <ins> pub fn solution(&self) -> ObjectSafetyViolationSolution { </ins> match self { ObjectSafetyViolation::SizedSelf(_) | ObjectSafetyViolation::SupertraitSelf(_) <del> | ObjectSafetyViolation::SupertraitNonLifetimeBinder(..) => {} </del> <ins> | ObjectSafetyViolation::SupertraitNonLifetimeBinder(..) => { ObjectSafetyViolationSolution::None } </ins> ObjectSafetyViolation::Method( name, MethodViolationCode::StaticMethod(Some((add_self_sugg, make_sized_sugg))), _, <del> ) => { err.span_suggestion( add_self_sugg.1, format!( "consider turning `{name}` into a method by giving it a `&self` argument" ), add_self_sugg.0.to_string(), Applicability::MaybeIncorrect, ); err.span_suggestion( make_sized_sugg.1, format!( "alternatively, consider constraining `{name}` so it does not apply to  trait objects" ), make_sized_sugg.0.to_string(), Applicability::MaybeIncorrect, ); } </del> <ins> ) => ObjectSafetyViolationSolution::AddSelfOrMakeSized { name: *name, add_self_sugg: add_self_sugg.clone(), make_sized_sugg: make_sized_sugg.clone(), }, </ins> ObjectSafetyViolation::Method( name, MethodViolationCode::UndispatchableReceiver(Some(span)), _, <del> ) => { err.span_suggestion( *span, format!("consider changing method `{name}`'s `self` parameter to be `&self`"), "&Self", Applicability::MachineApplicable, ); } </del> <ins> ) => ObjectSafetyViolationSolution::ChangeToRefSelf(*name, *span), </ins> ObjectSafetyViolation::AssocConst(name, _) | ObjectSafetyViolation::GAT(name, _) | ObjectSafetyViolation::Method(name, ..) => { <del> err.help(format!("consider moving `{name}` to another trait")); </del> <ins> ObjectSafetyViolationSolution::MoveToAnotherTrait(*name) </ins> } } }

Discussion:
made it so that we report all object safety violations at the same time. However, it also results in a redundant note: We should not add the same note multiple times.
Can we add a debug assertion for duplicate identical help messages? (sorta like we do for "Span must not be empty and have no suggestion" or "Suggestion may not have overlapping parts" ?
I guess we could, but I think there are multiple diagnostics that currently do this, so we'll have to fix them first.
Did not find tooo much... inside :
Change:
"allowed_fail": {},  "ignored": {},  "measured": {},  <del> "filtered_out": "{}" }}", </del> <ins> "filtered_out": {} }}", </ins> if state.failed == 0 { "ok" } else { "failed" }, state.passed, state.failed + state.allowed_fail,

Discussion:
The output of a test suite starting when using the json formatter represents "test_count" as a json string, like so: I would expect it to be a number like this:
It also seems like "filtered_out" on run finish is also unexectedly a string.
Change:
err.help("unlike in C++, Java, and C#, functions are declared in `impl` blocks"); err.help("see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information"); err <ins> } else if self.eat_keyword(kw::Struct) { match self.parse_item_struct() { Ok((ident, _)) => { let mut err = self.struct_span_err( lo.with_hi(ident.span.hi()), &format!("structs are not allowed in {adt_ty} definitions"), ); err.help("consider creating a new `struct` definition instead of nesting"); err } Err(err) => { err.cancel(); self.restore_snapshot(snapshot); self.expected_ident_found() } } </ins> } else { self.expected_ident_found() };

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 output is: <!-- The following is not always necessary. --Ideally the output should include a note informing the user that the declaration of another struct within a struct is not allowed and they should use separate declarations. (Wording might need a bit of tweaking). <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-terse
claim