jiebi/CodeConvo huggingface dataset:
Change:
<del> // 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. </del> <ins> // This test is an artifact of the old policy that `Box<T>` should not // be treated specially by the AST-borrowck. </ins> // <del> // 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. </del> <ins> // NLL goes back to treating `Box<T>` specially (namely, knowing that // it uniquely owns the data it holds). See rust-lang/rfcs#130. // revisions: ast mir //[ast] compile-flags: -Z borrowck=ast //[mir] compile-flags: -Z borrowck=mir // ignore-compare-mode-nll </ins> #![feature(box_syntax, rustc_attrs)] struct A {

Discussion:
The revision system lets encode different sets of errors for different invocations of the compiler. and normally attempts to catch cases where you left out expected error messages by saying "if you have any annotation in your file, then the set of such annotations needs to match the same set of errors that are actually emitted. However, if you combine these features, then for each revision (call it ) in the revisions list, at least one of your errors currently need to be written with the revision system in mind, e.g. If none of the error annotations include a revision (i.e., if they are all ), then thinks that the test has no error annotations, and thus treats it as a case where the compiler's error output is blindly accepted. That seems bad.
cc
This is surely no longer the case, because and annotations are now mandatory?
With annotation for warnings and errors being mandatory , and additionally annotations applying to all revisions , this should be non-issue.
Change:
_ => None, }; <ins> enum Defaults { Allowed, // See #36887 FutureCompatDisallowed, Deny, } </ins> let no_generics = hir::Generics::empty(); let ast_generics = node.generics().unwrap_or(&no_generics); let (opt_self, allow_defaults) = match node {

Discussion:
I tried this code: I expected to see this happen: It not work correctly as if you remove it shouts at you saying its unsupported and will be a hard error one day. Instead, this happened: defaults on GATs seem to function perfectly fine version from playground: cc this is probably should either be allowed or a hard error before stabilisation?
one issue is that we ignore defaults on the gat in impls
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
StorageLive(_36); _36 = (); _0 = Poll::<()>::Pending; <ins> StorageDead(_21); StorageDead(_35); StorageDead(_36); </ins> discriminant((*(_1.0: &mut {async fn body@$DIR/async_await.rs:15:18: 18:2}))) = 4; return; }

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
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. #![feature(macro_rules)] macro_rules! list ( ( ($($id:ident),*) ) => (()); ( [$($id:ident),*] ) => (()); ( {$($id:ident),*} ) => (()); ) macro_rules! tt_list ( ( ($($tt:tt),*) ) => (()); ) pub fn main() { list!( () ); list!( [] ); list!( {} ); tt_list!( (a, b, c) ); tt_list!( () ); } </ins>

Discussion:
The following macro won't work without the extra set of parens: Here's an example use: I'd like to remove those extra parens. It seems like [ field:ident),* ] should be unambiguous, but rustc doesn't like it. The actual error is . Also, it seems like it should tell me the other options so I have some clue what is going wrong.
Nominating for milestone 1, well-defined (part of figuring out what macros actually parse)
Related to which has to do with the implementation of parsing being able to stop / reset / restart. But I want to have some bug on file for well-definedness that says which grammar-class of macros we support. The current macro tutorial at has a little discussion of it, but is not entirely clear. I believe the class is "1-token predictive grammars" which is the non-backtracking subset of LL(1), quite limited. It's fine if that's our limitation -- it's still much more than in other languages -- but we ought to say so. (We discussed this in the nomination meeting today when we hit and decided to accept "some bug" for the well-definedness of the macro parser, and leave on the problem of its implementation)
Triage: still an issue. Specifically, the following fails FWIW, the example in the issue is one of many working versions, e.g. also works (called like: ).
Change:
} else if target.contains("x86_64-fortanix-unknown-sgx") { llvm_libunwind::compile(); } else if target.contains("linux") { <ins> // linking for Linux is handled in lib.rs </ins> if target.contains("musl") { <del> // linking for musl is handled in lib.rs </del> llvm_libunwind::compile(); <del> } else if !target.contains("android") { println!("cargo:rustc-link-lib=gcc_s"); </del> } } else if target.contains("freebsd") { println!("cargo:rustc-link-lib=gcc_s");

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
CT_BINUTILS_LINKER_DEFAULT="bfd" # CT_BINUTILS_PLUGINS is not set CT_BINUTILS_RELRO=m <del> CT_BINUTILS_EXTRA_CONFIG_ARRAY="" </del> <ins> CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-compressed-debug-sections=none" </ins> # CT_BINUTILS_FOR_TARGET is not set CT_ALL_BINUTILS_CHOICES="BINUTILS"

Discussion:
Hashbrown crate starts fail when running with: Full log file can be found in . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryLog</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
That's probably introduced by , but I haven't looked further yet.
Quick repro: and then edit: this repro is incorrect (I'm investigating)
I can reproduce with a simple hello-world when running in an older container. I think it's related to the user having binutils < 2.32, which would be fixed by Our new i586-gnu cross toolchain appears to be compressing by default, like the option, but I don't know why it's happening on this one and not any of our other crosstool-ng builds.
I found this commit in binutils: ;a=commit;h= That is, gas (the assembler) enables compression by default only on Linux/x86, which is why we haven't had this problem with other crosstool-ng toolchains. I'll explicitly turn that off.
great detective work thanks! :)
Change:
} } <del> Some(ItemLink { </del> <ins> res.def_id(self.cx.tcx).map(|page_id| ItemLink { </ins> link: ori_link.link.clone(), link_text: link_text.clone(), <del> page_id: res.def_id(self.cx.tcx), </del> <ins> page_id, </ins> fragment, }) }

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
cc
Rustdoc assumes that there is always a module for every primitive type referred to by a doc link, which is not the case in the code example above or any "minimal core" example not containing the primitive documentation modules.
Fixed in
Change:
// so emitting a lint would be redundant. if !lhs.projection.is_empty() { if let Some(def_id) = self.is_const_item(lhs.local) { <del> self.lint_const_item_usage(def_id, loc, |lint| { let mut lint = lint.build("attempting to modify a `const` item"); lint.note("each usage of a `const` item creates a new temporary - the original `const` item will not be modified"); lint }) </del> <ins> // Don't lint on writes through a pointer // (e.g. `unsafe { *FOO = 0; *BAR.field = 1; }`) if !matches!(lhs.projection.last(), Some(PlaceElem::Deref)) { self.lint_const_item_usage(def_id, loc, |lint| { let mut lint = lint.build("attempting to modify a `const` item"); lint.note("each usage of a `const` item creates a new temporary - the original `const` item will not be modified"); lint }) } </ins> } } // We are looking for MIR of the form:

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. --I have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!
Change:
let exec_suffix = os::exec_suffix(); for ct: str in new { if (exec_suffix != "" && str::ends_with(ct, exec_suffix)) || <del> (exec_suffix == "" && !str::starts_with(ct, "./lib")) { </del> <ins> (exec_suffix == "" && !str::starts_with(fs::basename(ct), "lib")) { </ins> #debug("  bin: %s", ct); // FIXME: need libstd fs::copy or something run::run_program("cp", [ct, c.bindir]);

Discussion:
The documentation of and functions. In actual behaviour and , selects elements from when the mask bit is set and from otherwise. The Rust standard library documentation describes the other way around.
I believe I see the problem. Working on a PR now.
Change:
#[inline] fn next(&mut self) -> Option<Self::Item> { <del> <Self as StepBySpecIterator>::spec_next(self) </del> <ins> if self.first_take { self.first_take = false; self.iter.next() } else { self.iter.nth(self.step) } </ins> } #[inline]

Discussion:
The following snippet demonstrates the problem: It prints: I expect second iterator to produce the same result as for the third one.
Regression from 1.28.0 to 1.29.0. Introduced in
The problem is interaction between and . ignores the inner working of StepBy. Test-case reduced to using without .
From a cursory look, it seems to me that the problem is that and are out of sync. StepBy specifically allows for the underlying iterator, either or . If both and follow the same one, the bug shouldn't occur. In other words, if is specialized and overrides the default, then needs to be specialized as well.
Change:
} impl<T: Copy> SpecFill<T> for [T] { <del> default fn spec_fill(&mut self, value: T) { for item in self.iter_mut() { *item = value; } } } impl SpecFill<u8> for [u8] { fn spec_fill(&mut self, value: u8) { // SAFETY: this is slice of u8 unsafe { let ptr = self.as_mut_ptr(); let len = self.len(); write_bytes(ptr, value, len); } } } impl SpecFill<i8> for [i8] { fn spec_fill(&mut self, value: i8) { // SAFETY: this is slice of i8 unsafe { let ptr = self.as_mut_ptr(); let len = self.len(); write_bytes(ptr, value as u8, len); } } } impl SpecFill<bool> for [bool] { fn spec_fill(&mut self, value: bool) { // SAFETY: this is slice of bool unsafe { let ptr = self.as_mut_ptr(); let len = self.len(); write_bytes(ptr, value as u8, len); </del> <ins> fn spec_fill(&mut self, value: T) { if size_of::<T>() == 1 { // SAFETY: The size_of check above ensures that values are 1 byte wide, as required // for the transmute and write_bytes unsafe { let value: u8 = transmute_copy(&value); write_bytes(self.as_mut_ptr(), value, self.len()); } } else { for item in self.iter_mut() { *item = value; } </ins> } } }

Discussion:
Specialized slice::fill implementations are not inlined even though they would compile down to pretty much just a single memset-call. The function below represents manual inlining of . () I haven’t tested it in any way, but I suspect that this can be fixed by marking as . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: C-enhancement, T-libs-impl, I-slow, E-easy
claim
Don't you need at the very least (but not necessarily ) to actually guarantee cross-crate-inlining eligibility with the default no-LTO profile? It'd certainly make sense to add that to all of the impls in IMO.
It being generic is sufficient for being eligible because the monomorphized function is only created in the consuming crate once all the generics have been filled in. Adding on top just encourages it further.
Change:
// Get a value from the rustdoc-vars div, which is used to convey data from // Rust to the JS. If there is no such element, return null. const getVar = (function getVar(name) { <del> const el = document.getElementById("rustdoc-vars"); </del> <ins> const el = document.querySelector("head > meta[name='rustdoc-vars']"); </ins> return el ? el.attributes["data-" + name].value : null; });

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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.
Change:
<ins> error: recursive delegation is not supported yet --> $DIR/ice-issue-124347.rs:5:18 | LL |     reuse Trait::foo { &self.0 } |                  ^^^ callee defined here error: recursive delegation is not supported yet --> $DIR/ice-issue-124347.rs:9:7 | LL | reuse foo; |       ^^^ callee defined here error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
cc
Change:
<ins> // Test for #79487 // check-pass #![allow(dead_code)] mod sha2 { extern "C" { pub(super) fn GFp_sha512_block_data_order(); } } 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</details
I'm seeing this one as well. Host is a standard Github Actions container. Not sure if the below information is helpful but its additional to the above posted by HYG-YT.
I have to temporarily degrade the version of my nightly installation to 11-24 to make sure everything is functional (it's a discord bot made with twilight-rs)
Similarly, I'm attempting to knock my version back a couple of days as well-- yet to succeed but that's mostly me wrestling with my actions configuration.
I have the same on my Raspberry Pi 3 (Debian 10, Linux 4.19.66):
I can reproduce with on . searched toolchains through regression in Regressed in , cc
MCVE:
Assigning .
I updated to the latest nightly (2020-11-29) and it still fails.
Wait for next nightly. The current one doesn't contain the fix PR.
Got it!
you can also try the latest master using
Change:
exit 0 fi <del> if grep -q fail "$TOOLSTATE_FILE"; then exit 4 fi </del> <ins> # abort compilation if an important tool doesn't build # (this code is reachable if not on the nightly channel) status_check "beta_required" </ins>

Discussion:
I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.
Change:
"libc", "merge", "num_cpus", <ins> "once_cell", </ins> "opener", "pretty_assertions", "serde",

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).