jiebi/CodeConvo huggingface dataset:
Change:
} #[cfg(target_env = "musl")] <del> #[link(name = "unwind", kind = "static", cfg(target_feature = "crt-static"))] #[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] extern "C" {} </del> <ins> cfg_if::cfg_if! { if #[cfg(all(feature = "llvm-libunwind", feature = "system-llvm-libunwind"))] { compile_error!("`llvm-libunwind` and `system-llvm-libunwind` cannot be enabled at the same time"); } else if #[cfg(feature = "llvm-libunwind")] { #[link(name = "unwind", kind = "static")] extern "C" {} } else if #[cfg(feature = "system-llvm-libunwind")] { #[link(name = "unwind", kind = "static-nobundle", cfg(target_feature = "crt-static"))] #[link(name = "unwind", cfg(not(target_feature = "crt-static")))] extern "C" {} } else { #[link(name = "unwind", kind = "static", cfg(target_feature = "crt-static"))] #[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] extern "C" {} } } </ins> // When building with crt-static, we get `gcc_eh` from the `libc` crate, since // glibc needs it, and needs it listed later on the linker command line. We

Discussion:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.
Change:
use crate::context::LintContext; <del> use crate::lints::{NoopMethodCallDiag, SuspiciousDoubleRefDiag}; </del> <ins> use crate::lints::{ NoopMethodCallDiag, SuspiciousDoubleRefCloneDiag, SuspiciousDoubleRefDerefDiag, }; </ins> use crate::LateContext; use crate::LateLintPass; use rustc_hir::def::DefKind;

Discussion:
If I have a type , and a trait that is implemented for both and , is a valid way to get a reference from an object of type . But since beta 1.71, this emits a warning. I have no idea what the warning is trying to convey, what "double reference" is referring to, or what "the inner type" is. No response
cc
Ah. then I think this lint shouldn't apply to since can mean specifically to borrow . But I think this should still apply to and
(sorry)
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
mod perf_counter { use super::{NANOS_PER_SEC}; <del> use crate::sync::Once; </del> <ins> use crate::sync::atomic::{AtomicUsize, Ordering::SeqCst}; </ins> use crate::sys_common::mul_div_u64; use crate::sys::c; use crate::sys::cvt;

Discussion:
I was trying to troubleshoot this issue: and eventually we figured out that on my machine parktimeout wasn't waking up. I wrote this simple test code which demonstrates the issue: Most of the time it will only print this: Every once in a while it will finish normally. This behavior happens on stable and nightly and I tried a handfull of stable versions all the way back to 1.12 and they all got stuck. Windows (both msvc and gnu appear to never get stuck (at least I couldn't reproduce the issue)). I was able to duplicate this an another mac as well (both running 10.14) If only a single thread is started (or the park happens on the main thread) then I can't reproduce. I'm on 10.14; uname:
This definitely seems broken. Here's dtruss output:
It's a deadlock on the ONCE here:
As a workaround, everything should work fine as long as you construct an at least once in your process before parking.
Doesn't seem to help :(
Oh right sorry, you actually have to subtract two Instants to force that Once to complete. If you instead do at the start of main, it prevents the deadlock.
Works perfectly now! Thanks!
Change:
#![cfg_attr(not(test), feature(generator_trait))] #![cfg_attr(test, feature(test))] #![feature(allocator_api)] <ins> #![feature(array_chunks)] </ins> #![feature(allow_internal_unstable)] #![feature(arbitrary_self_types)] #![feature(box_patterns)]

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
<ins> #[derive(Eq, PartialEq)] struct Test { a: &'b str, //~^ ERROR use of undeclared lifetime name `'b` //~| ERROR use of undeclared lifetime name `'b` } trait T { fn foo(&'static self) {} } impl T for Test { fn foo(&'b self) {} //~ ERROR use of undeclared lifetime name `'b` } fn main() {} </ins>

Discussion:
In case there is an undeclared lifetime in an ADT deriving a wrong help message is emited causes the following error thx, bye
There are two things here: 1) the suggestion should try and identify spans coming from macro expansion and not suggest changes 2) in this case expands to the following: Note the param, which could avoid having any lifetimes and thing would work correctly. We can probably change the desugaring to not specify the lifetime and then we would avoid the second unnecessary duplicated error. would you happen to know if there's any clear negative in doing 2 above and if not, point me in the right direction in to make that change?
I believe that we can't remove the explicit lifetime here. This would allow for even if is only implemented for .
Change:
extern crate libc; fn main() { <del> let foo: *mut libc::c_void; let cb: &mut Fn() = unsafe { &mut *(foo as *mut Fn()) //~^ ERROR use of possibly uninitialized variable: `foo` </del> <ins> let ptr: *mut () = 0 as *mut _; let _: &mut Fn() = unsafe { &mut *(ptr as *mut Fn()) //~^ ERROR illegal cast </ins> }; }

Discussion:
This is done when compiling repository. Use on either the entire handmadehero crate, or handmadelibsdl. Warning: Ugly, code ahead! Cleaned up repo: It does need to be across crate lines, and needs to be returned in a result, afaict.
The issue is that I should not be able to write because is a [T]. Same with .
Actually, to that end, why is bigger than a anything? Why is a a fat pointer at all?
Very similar to , , .
Yes it is, pretty much the same. A should not be differently sized from a , at least IMHO, so why is it?
is a with fewer guarantees; one can convert between them freely (if you ensure the guarantees are maintained for -). In particular, this means is a fat pointer to match .
That is weird...
NVM, I now understand why it is a fat pointer. However, this should be an easy fix, right? Why is a mut [T] seen as the same size as a mut T in rustc? Well, now it isn't, so is fixed, but it still panics at .
Change:
mod tests; use crate::fmt; <del> use crate::io::{self, BufRead, Initializer, IoSlice, IoSliceMut, Read, Write}; </del> <ins> use crate::io::{self, BufRead, Initializer, IoSlice, IoSliceMut, Read, Seek, SeekFrom, Write}; </ins> /// A reader which is always at EOF. ///

Discussion:
You can create an empty io-reader with , which returns an . That doesn't implement the trait. However, I don't see any reason why it shouldn't.
I don't understand how a reader which is always at EOF should be seekable. Can you please explain more about it?
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having implemented for . It allows it to be passed to more generic code.
Did you hit a case where you actually wanted to do this?
In is discussing ways to implement a 307/308 HTTP redirect. Those two codes (in contrast to 301/302/303) require the payload to be sent after the redirect. However, parts of the payload may already have been sent to the server, before the server responds with the redirect. With a generic API taking an as Payload, it's not possible to seek back to the beginning. Thus, one suggestion is to use instead. To allow an empty body (e.g. for a GET request), it would be nice to keep using . While will probably decide to follow a different way for those redirects, I still think this pattern makes sense to support.
Change:
for s in b.stmts.iter() { bcx = trans_stmt(bcx, *s); } <ins> if dest != expr::Ignore { let block_ty = node_id_type(bcx, b.id); if b.expr.is_none() || type_is_zero_size(bcx.ccx(), block_ty) { dest = expr::Ignore; } } </ins> match b.expr { Some(e) => { bcx = expr::trans_into(bcx, e, dest);

Discussion:
Was trying to find another bug, found this bug! That code will fail with
I'll take it
Different testcases: EDIT: Found more testcases
Interesting. I'm looking into it. Not sure what is causing this, though.
Another testcase: (The and are both necessary.)
Even simpler example: Debug Log EDIT: Making the block return doesn't raise this issue.
My final testcase:
Could this be related to the no-argument version of lambda block expressions that were used in syntax? Looking in , there's a comment to this form of lambda expressions used with . As far as why doesn't raise the issue, maybe that's parsed as a block expression instead?
I don't see how it could be related. The error here has to do with a (or just zero-sized? I'm not sure) result of a block being stored somewhere. I'm not even sure the assert needs to be that strict.
Yet another test case to consider:
thanks! I'll get back to debug this in a bit
Change:
// failed (so the return value of this method should not be used) fn process_errors(&self, errors: &Vec<RegionResolutionError>) -> Vec<RegionResolutionError> { <ins> debug!("process_errors()"); </ins> let mut var_origins = Vec::new(); let mut trace_origins = Vec::new(); let mut same_regions = Vec::new();

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
// Overwrite bootstrap's `rustc` wrapper overwriting our flags. cargo.env("RUSTC_DEBUG_ASSERTIONS", "true"); // Let cargo-miri know where xargo ended up. <del> cargo.env("XARGO", builder.out.join("bin").join("xargo")); </del> <ins> cargo.env("XARGO_CHECK", builder.out.join("bin").join("xargo-check")); </ins> let mut cargo = Command::from(cargo); if !try_run(builder, &mut cargo) {

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination.
Change:
compiler.host, target_compiler.host, target); <del> let libdir = build.sysroot_libdir(&target_compiler, target); let out_dir = build.cargo_out(&compiler, Mode::Libtest, target); add_to_sysroot(&out_dir, &libdir); </del> <ins> add_to_sysroot(&build.sysroot_libdir(target_compiler, target), &libtest_stamp(build, compiler, target)); </ins> } /// Build the compiler.

Discussion:
Rustbuild compiles the compiler in a particular location and is then responsible for copying artifacts over to the actual structure the compiler is expecting (e.g. rustbuild assembles a sysroot). In order to handle stale folders rustbuild , deduplicated by hash. This pretty obviously, though, doesn't work with multiple versions of the same library! We should probably call Cargo with and learn about compiled artifacts, that way we can copy precisely what we need to into the sysroot.
Change:
in_module_is_extern)) = worklist.pop() { // We have to visit module children in deterministic order to avoid // instabilities in reported imports (#43552). <del> in_module.for_each_child_stable(self, |this, ident, ns, name_binding| { </del> <ins> in_module.for_each_child(self, |this, ident, ns, name_binding| { </ins> // avoid imports entirely if name_binding.is_import() && !name_binding.is_extern_crate() { return; } // avoid non-importable candidates as well

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
| = note: expected type parameter `_` found reference `&_` <del> = note: the caller chooses a type for `T` which can be different from `&T` </del> note: `T` does not implement `Clone`, so `&T` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 |

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
<ins> // build-fail // error-pattern: overflow evaluating the requirement `(): Sized` // error-pattern: function cannot return without recursing // Regression test for #91949. // This hanged *forever* on 1.56, fixed by #90423. #![recursion_limit = "256"] struct Wrapped<T>(T); struct IteratorOfWrapped<T, I: Iterator<Item = T>>(I); impl<T, I: Iterator<Item = T>> Iterator for IteratorOfWrapped<T, I> { type Item = Wrapped<T>; fn next(&mut self) -> Option<Wrapped<T>> { self.0.next().map(Wrapped) } } fn recurse<T>(elements: T) -> Vec<char> where T: Iterator<Item = ()>, { recurse(IteratorOfWrapped(elements).map(|t| t.0)) } fn main() { recurse(std::iter::empty()); } </ins>

Discussion:
This code is not expected to compile successfully: ` This can't compile successfully because calls recursively, which then calls , and so on... However up to stable 1.55, the code failed to compile quickly with the default recursion limit. On the , you can see it even handling without timeout. However, and it no longer reaches a compilation error in time with . Still just as slow on nightly (). label: regression-from-stable-to-stable, perf-regression, I-compiletime, T-compiler, E-needs-bisection Comes from: Rough estimate on my machine: In the area of being -, the time more-than doubles for each increase of the recursion limit by or , so it really is exponential AFAICT.
Possibly related to ?
Bisected to , cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summarysearched nightlies: from nightly-2021-06-01 to nightly-2021-12-08 regressed nightly: nightly-2021-09-03 searched commit range: regressed commit: Host triple: x86_64-unknown-linux-gnu Reproduce with: </details label -E-needs-bisection
That PR seems incremental-compilation related. This leaves the question of whether the regression also happens without incremental compilation turned on, and whether or not it happens at the same point.
This is almost certainly the same issue as then.
Hard to know for certain until has a mvce. Also note that, as far as I understand, is observable with whereas this bug only appears with . (I somehow forgot to mention that...)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Retested since landed on nightly: rustc 1.55.0 ( 2021-09-06): 13.1 seconds rustc 1.59.0-nightly ( 2021-12-26): 10.6 seconds
Seems to have fixed the problem, indeed. label E-needs-test.
Change:
}; let cstore = Rc::new(CStore::new(token::get_ident_interner())); <del> let mut sess = build_session(sopts, input_file_path, descriptions, </del> <ins> let sess = build_session(sopts, input_file_path, descriptions, </ins> cstore.clone()); rustc_lint::register_builtins(&mut sess.lint_store.borrow_mut(), Some(&sess)); <del> if sess.unstable_options() { sess.opts.show_span = matches.opt_str("show-span"); } </del> let mut cfg = config::build_configuration(&sess); target_features::add_configuration(&mut cfg, &sess);

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
$$(RUSTFLAGS$(1)_$(4)_T_$(2))  --out-dir $$(@D)  -C extra-filename=-$$(CFG_FILENAME_EXTRA)  <ins> -C metadata=$$(CFG_FILENAME_EXTRA)  </ins> $$< @touch -r $$@.start_time $$@ && rm $$@.start_time $$(call LIST_ALL_OLD_GLOB_MATCHES, 

Discussion:
A bunch of my nightly builds are now generating the error: error: the current crate is indistinguishable from one of its dependencies: it has the same crate-name and was compiled with the same arguments. This will result in symbol conflicts between the two. [E0519] This is likely due to the revamp of symbol names, but it's also unfortunately a regression on nightly. I think what's happening here is that Cargo isn't passing to rustdoc (because it can't) and then the libc crate is conflicting with the in-tree libc crate. cc
Ah, and an example of a
I'm hitting this too.
cc
specifically with libc, or with other crate names?
So I'm trying to figure out if the right answer here is that we should just be passing in metadata to rustdoc? Seems plausible.
Hm, in rustdoc we actually don't care about symbol name conflict, so we could indicate that to the crate loader?
The analysis of the underlying reason by seems plausible to me, by the way.
Maybe, but it seems sloppy to me -- I mean, why don't we care? The signatures might well be different, for example, so it might well matter. In any case, I'm trying to understand what is leading us to get this conflict still (I haven't reproduced it yet -- what target do I need to use?). I feel like I'm still missing something. From what I can tell, the error comes when generating docs for the crate -- so why is it accessing anyway? And doesn't give metadata when building? (Do we tell rustdoc where to find all dependencies the same way we tell rustc? I would expect maybe it's falling back to some other behavior and scraping things off the file system?) Perhaps part of it is that I am a bit removed from the details of how a lot of this lower level stuff works.
ok, I see now that this error is not when bootstrapping.
Further investigation reveals that somehow we do not seem to be supplying except for tests. Oops. That will presumably fix this conflict, though not in the best possible way -- because now the makefile libc will have a disambiguator, so the rustdoc version would have a disambiguator of just and everybody is happy.

That said, it seems to me that should take a argument -- presumably it should take the same arguments as rustc, since it basically invokes rustc.
Can you elaborate on that?
I believe this is fixed in , explained here: To elaborate on the lack of metadata, rustdoc simply doesn't accept flags, so that's why it's not being passed :)
did you actually check whether this is fixed? I wonder if it's worth trying to allow rustdoc to accept -C metadata -- I guess so long as it doesn't matter, it doesn't matter.
Nah I was hoping to test with today's nightly, but that's blocked on I'm pretty confident that the change would fix this, however.
FYI rustc 1.9.0-nightly ( 2016-03-29) fixed this issue for me
Change:
fn let_binding_suggestion(&mut self, err: &mut Diagnostic, ident_span: Span) -> bool { if let Some(Expr { kind: ExprKind::Assign(lhs, ..), .. }) = self.diagnostic_metadata.in_assignment <del> && let ast::ExprKind::Path(None, _) = lhs.kind </del> <ins> && let ast::ExprKind::Path(None, ref path) = lhs.kind </ins> { if !ident_span.from_expansion() { <ins> let (span, text) = match path.segments.first() { Some(seg) if let Some(name) = seg.ident.as_str().strip_prefix("let") => { // a special case for #117894 let name = name.strip_prefix("_").unwrap_or(name); (ident_span, format!("let {name}")) } _ => (ident_span.shrink_to_lo(), "let ".to_string()), }; </ins> err.span_suggestion_verbose( <del> ident_span.shrink_to_lo(), </del> <ins> span, </ins> "you might have meant to introduce a new binding", <del> "let ".to_string(), </del> <ins> text, </ins> Applicability::MaybeIncorrect, ); return true;

Discussion:
I accidentally typoed an underscore instead of a space between and the name of the new variable I was trying to declare. If a binding isn't found, and it starts with (or frankly , if you forget/miss the space completely), it seems like it would be more likely to suggest ( plus a space) rather than the current suggestion of an additional . No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
interesting, I'd like to have a try. but might not solve it quicklly casuze I am new to rustc
sounds good! feel free to ask for help if you need it, but the implementation should be fairly simple. assign