jiebi/CodeConvo huggingface dataset:
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! And nominating for compiler team prioritization.

Discussion:
<del> Subproject commit d8e6e4cfcd83d555bd7717ea24224b777ed75773 </del> <ins> Subproject commit 1ff81c1b6d7abdcc9ee47f4a8ab175082cad4421 </ins>
Change:
Using . No environment changes other than installing Rust itself.
Has it started with latest nightly? It'd be good to rule out AppVeyor change by installing previously working nightly.
The compiler-builtins CI now fails with the same error. The latest working nightly is 2020-03-14. Looks like it is related to changes from which included in link args.
modify labels: +E-needs-mcve cc FWIW depend on two libraries:
Ugh, mingw has a stupid amount of circular dependencies in its libraries... What I am more concerned about is why Rust CI didn't catch this. Maybe it's because it is using an older mingw version. We should considering upgrading it.
I'd love to upgrade MinGW on the CI as it would help me with a few thing but there is a problem. Upstream no longer provides prebuilt GCC and latest version available had issue where it ran out of memory on the CI: I can help with building GCC or providing builds but I don't really know how to start.
I managed to reproduce this locally. It only happens if you don't have MSYS installed, in which case rustc will use the gcc and libraries from the component. This is a bit worrying, since it means that isn't being properly tested in CI.

Discussion:
"-lgcc".to_string(), "-lgcc_eh".to_string(), "-lpthread".to_string(), <ins> // libpthread depends on libmsvcrt, so we need to link it *again*. "-lmsvcrt".to_string(), </ins> "-lkernel32".to_string(), ], );
Change:
` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign

Discussion:
// A rest pattern `..`. self.bump(); // `..` PatKind::Rest <ins> } else if self.check(&token::DotDotDot) && !self.is_pat_range_end_start(1) { self.recover_dotdotdot_rest_pat(lo) </ins> } else if let Some(form) = self.parse_range_end() { self.parse_pat_range_to(form)? // `..=X`, `...X`, or `..X`. } else if self.eat_keyword(kw::Underscore) {

Ok(pat) } <ins> /// Recover from a typoed `...` pattern that was encountered /// Ref: Issue #70388 fn recover_dotdotdot_rest_pat(&mut self, lo: Span) -> PatKind { // A typoed rest pattern `...`. self.bump(); // `...` // The user probably mistook `...` for a rest pattern `..`. self.struct_span_err(lo, "unexpected `...`") .span_label(lo, "not a valid pattern") .span_suggestion_short( lo, "for a rest pattern, use `..` instead of `...`", "..".to_owned(), Applicability::MachineApplicable, ) .emit(); PatKind::Rest } </ins> /// Try to recover the more general form `intersect ::= $pat_lhs @ $pat_rhs`. /// /// Allowed binding patterns generated by `binding ::= ref? mut? $ident @ $pat_rhs`

<ins> struct Foo(i32); fn main() { let Foo(...) = Foo(0); //~ ERROR unexpected `...` let [_, ..., _] = [0, 1]; //~ ERROR unexpected `...` let _recovery_witness: () = 0; //~ ERROR mismatched types } </ins>

<ins> error: unexpected `...` --> $DIR/issue-70388-recover-dotdotdot-rest-pat.rs:4:13 | LL |     let Foo(...) = Foo(0); |             ^^^ |             | |             not a valid pattern |             help: for a rest pattern, use `..` instead of `...` error: unexpected `...` --> $DIR/issue-70388-recover-dotdotdot-rest-pat.rs:5:13 | LL |     let [_, ..., _] = [0, 1]; |             ^^^ |             | |             not a valid pattern |             help: for a rest pattern, use `..` instead of `...` error[E0308]: mismatched types --> $DIR/issue-70388-recover-dotdotdot-rest-pat.rs:6:33 | LL |     let _recovery_witness: () = 0; |                            --   ^ expected `()`, found integer |                            | |                            expected due to this error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Change:
Const generics causes monomorphization to compare constants by identity instead of structurally. This means that two different references to equal data will compare as unequal. The root problem is in which puts the of a function into a . Since the 's s contain constants, hashing these constants will cause structurally equal constants to have different hashes. For this has been solved by hashing the actual data and not things like pointers. For comparison we have which does a more appropriate version of comparison. I tried this code: I expected to see this happen: successful compilation just as if the type were Instead, this happened: cc cc It's a footgun that and especially can be compared for equality. Technically a is value/structurally equal to any other . We may need that impl for query return value hashing though, not sure.
There's two ways that I see that we can use to go forward: from and everything that depends on it. This requires some wrapper helpers (forwarding to ) around the return values of queries as query return types need impls I think. implement to use and . This may cause some things to become slow, as more work is done. We could benchmark this as a first try.
isn't relevant here, you should have fully normalized constants by the time of the monomorphization collector (i.e. no ), anything else is a bug. Keep in mind types have the same problem with and .
Ok, but even ignoring any other than , the only place that correctly compares is , so we can pull that out as a common function for comparing . That'll still have to have access to a in order to be able to fetch the that a const pointer points to.
You shouldn't need to compare fully normalized monomorphic things, interning should deduplicate everything by-typesystem-semantic-value.
Oh, as a side mention, if you need to validate that the typesystem doesn't contain any non-deduplicatable constants (e.g. references), we can do it in WF checking, post-.
I don't think we can run into issues with here, so not marking it as blocking.
this is now fixed by valtrees: needs test though:

Discussion:
<ins> // build-pass #![feature(adt_const_params)] #![allow(incomplete_features)] pub fn function_with_bytes<const BYTES: &'static [u8; 4]>() -> &'static [u8] { BYTES } pub fn main() { assert_eq!(function_with_bytes::<b"AAAA">(), &[0x41, 0x41, 0x41, 0x41]); assert_eq!(function_with_bytes::<{ &[0x41, 0x41, 0x41, 0x41] }>(), b"AAAA"); } </ins>
Change:
According to , the return type of is (an alias for ), but in Rust we use (an alias for ): Which one is right?
winapi BOOL (c_int/i32) -- I suspect that this has been wrong since forever. Presumably we haven't noticed because in practice the values are always just and usually not 0 modulo 256, either, so we aren't spuriously wrong, and the value is passed in a register -- which on ~all platforms is 32-64bits anyway. Presumably though we should just fix this; cc who originally these in and cc more broadly. (Also, can I just say that having both BOOLEAN and BOOL as aliases and they mean different things is pretty confusing?)
This is practically guaranteed to just be a typo on my end, so BOOL is most likely right.
Yeah, that one is on Microsoft... .

Discussion:
pub fn ioctlsocket(s: SOCKET, cmd: c_long, argp: *mut c_ulong) -> c_int; pub fn InitializeCriticalSection(CriticalSection: *mut CRITICAL_SECTION); pub fn EnterCriticalSection(CriticalSection: *mut CRITICAL_SECTION); <del> pub fn TryEnterCriticalSection(CriticalSection: *mut CRITICAL_SECTION) -> BOOLEAN; </del> <ins> pub fn TryEnterCriticalSection(CriticalSection: *mut CRITICAL_SECTION) -> BOOL; </ins> pub fn LeaveCriticalSection(CriticalSection: *mut CRITICAL_SECTION); pub fn DeleteCriticalSection(CriticalSection: *mut CRITICAL_SECTION);
Change:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-01-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-08 searched commits: from to regressed commit:
is the cause. Reduced to: clarified to: clarified further to:

Discussion:
ExprKind::MethodCall(_, _) => "a method call", ExprKind::Call(_, _) => "a function call", ExprKind::Await(_) => "`.await`", <ins> ExprKind::Err => return Ok(with_postfix), </ins> _ => unreachable!("parse_dot_or_call_expr_with_ shouldn't produce this"), } );

<ins> fn main() { expr as fun()(:); //~ ERROR expected expression } </ins>

<ins> error: expected expression, found `:` --> $DIR/issue-70552-ascription-in-parens-after-call.rs:2:19 | LL |     expr as fun()(:); |                   ^ expected expression error: aborting due to previous error </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-22 searched commits: from to regressed commit:
Simplified: and cc ()
Fix up at

Discussion:
f: impl FnOnce(&mut Self) -> (&'hir [hir::Param<'hir>], hir::Expr<'hir>), ) -> hir::BodyId { let prev_gen_kind = self.generator_kind.take(); <ins> let task_context = self.task_context.take(); </ins> let (parameters, result) = f(self); let body_id = self.record_body(parameters, result); <ins> self.task_context = task_context; </ins> self.generator_kind = prev_gen_kind; body_id }

<ins> // edition:2018 async fn fun() { [1; ().await]; //~^ error: `await` is only allowed inside `async` functions and blocks //~| error: `.await` is not allowed in a `const` //~| error: `loop` is not allowed in a `const` //~| error: `.await` is not allowed in a `const` //~| error: the trait bound `(): std::future::Future` is not satisfied } fn main() {} </ins>

<ins> error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-70594.rs:4:9 | LL | async fn fun() { |          --- this is not `async` LL |     [1; ().await]; |         ^^^^^^^^ only allowed inside `async` functions and blocks error[E0744]: `.await` is not allowed in a `const` --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ error[E0658]: `loop` is not allowed in a `const` --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ | = note: see issue #52000 <https://github.com/rust-lang/rust/issues/52000> for more information = help: add `#![feature(const_loop)]` to the crate attributes to enable error[E0744]: `.await` is not allowed in a `const` --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ error[E0277]: the trait bound `(): std::future::Future` is not satisfied --> $DIR/issue-70594.rs:4:9 | LL |     [1; ().await]; |         ^^^^^^^^ the trait `std::future::Future` is not implemented for `()` | ::: $SRC_DIR/libcore/future/mod.rs:LL:COL | LL |     F: Future, |        ------ required by this bound in `std::future::poll_with_context` error: aborting due to 5 previous errors Some errors have detailed explanations: E0277, E0658, E0728, E0744. For more information about an error, try `rustc --explain E0277`. </ins>
Change:
It seems that over the last 24 hours the link to the Rustdocs for the compiler has turned into a 404. At the bottom of the README there is a link to this url: which currently returns a Not Found response. I'm not sure if this is a problem caused by any recent changes to rustc or by the doc hosting itself. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The crate was renamed, the new link is Should be an easy fix, but I don't know where that page is located
Oh, the readme, duh
claim Seems easy enough for the first issue

Discussion:
[rust-discord]: https://discord.gg/rust-lang [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html <del> [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ </del> <ins> [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ </ins> ## License
Change:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit:
This is presumably due to -- cc
This was . Tagging it as . Not removing nomination until we can assign this issue.
assign (assigning based on claim that this was injected by PR )
This is the feature where for a with a missing type will look at the body and get the type from there. We should replace all regions in that situation with , just so the code which ICEs here will continue to ICE for legitimate bugs.
Doesn't reproduce with ( ):
Hmmmm, I'm not sure I agree with that assessment, unless -- well -- I guess you're saying that the "correct static type" for any such expression would be anyway?
yes, this is recovery for a guaranteed error, after all. A slightly more aggressive example: Results in this query stack for the ICE: I have no idea why changing to changes anything but they should both ICE IMO (before we switch to replacing erased regions with ). I'm now worried there are other places in which is used to extract some type and "export" it outside of the context of the body, without the necessary precautions.

Discussion:
} } <del> ty </del> <ins> // Typeck doesn't expect erased regions to be returned from `type_of`. tcx.fold_regions(&ty, &mut false, |r, _| match r { ty::ReErased => tcx.lifetimes.re_static, _ => r, }) </ins> } fn report_assoc_ty_on_inherent_impl(tcx: TyCtxt<'_>, span: Span) {

//~| HELP provide a type for the item //~| SUGGESTION C: i32 <ins> const D = &&42; //~^ ERROR missing type for `const` item //~| HELP provide a type for the item //~| SUGGESTION D: &&i32 </ins> static S = Vec::<String>::new(); //~^ ERROR missing type for `static` item //~| HELP provide a type for the item

LL | const C = 42; |       ^ help: provide a type for the item: `C: i32` <ins> error: missing type for `const` item --> $DIR/const-no-type.rs:38:7 | LL | const D = &&42; |       ^ help: provide a type for the item: `D: &&i32` </ins> error: missing type for `static` item <del> --> $DIR/const-no-type.rs:38:8 </del> <ins> --> $DIR/const-no-type.rs:43:8 </ins> | LL | static S = Vec::<String>::new(); |        ^ help: provide a type for the item: `S: std::vec::Vec<std::string::String>` error: missing type for `static mut` item <del> --> $DIR/const-no-type.rs:43:12 </del> <ins> --> $DIR/const-no-type.rs:48:12 </ins> | LL | static mut SM = "abc"; |            ^^ help: provide a type for the item: `SM: &str`

LL | static mut SM2 = "abc"; |            ^^^ help: provide a type for the item: `SM2: <type>` <del> error: aborting due to 6 previous errors </del> <ins> error: aborting due to 7 previous errors </ins>
Change:
When running on of the crate, panics: Platform: macos
FYI, this appears to be a macOS-specific bug:
Minimal repro:

Discussion:
// // We could remove this hack whenever we decide to drop macOS 10.10 support. if self.tcx.sess.target.target.options.is_like_osx { <del> assert_eq!(alloc.relocations().len(), 0); let is_zeroed = { // Treats undefined bytes as if they were defined with the byte value that // happens to be currently assigned in mir. This is valid since reading // undef bytes may yield arbitrary values. // // FIXME: ignore undef bytes even with representation `!= 0`. // // The `inspect` method is okay here because we checked relocations, and // because we are doing this access to inspect the final interpreter state // (not as part of the interpreter execution). alloc </del> <ins> // The `inspect` method is okay here because we checked relocations, and // because we are doing this access to inspect the final interpreter state // (not as part of the interpreter execution). // // FIXME: This check requires that the (arbitrary) value of undefined bytes // happens to be zero. Instead, we should only check the value of defined bytes // and set all undefined bytes to zero if this allocation is headed for the // BSS. let all_bytes_are_zero = alloc.relocations().is_empty() && alloc </ins> .inspect_with_undef_and_ptr_outside_interpreter(0..alloc.len()) .iter() <del> .all(|b| *b == 0) }; let sect_name = if is_zeroed { </del> <ins> .all(|&byte| byte == 0); let sect_name = if all_bytes_are_zero { </ins> CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_bss0") } else { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_data0")

<ins> // Regression test for https://github.com/rust-lang/rust/issues/70673. // run-pass #![feature(thread_local)] #[thread_local] static A: &u8 = &42; fn main() { dbg!(*A); } </ins>
Change:
With musl we can generate static binaries just fine. But without much work we can even generate a static position independent executable, which would enable Address Space Layout Randomization for free. For this to work, we need: rustc: gcc: remove any has or replace musl with is a program printing all the AUX vectors, which also contains the entry address of the program. As you can see it changes with every start of the program.
If there will be no native support, at least ship along with and add some possibility to change the startup file.
something like:
The workaround may be similar to what I recently did to statically link to bionic libc () - produce a with and then link manually. ( has nice defaults, but is pretty inflexible when you need to do something different with linking, modulo custom target specifications.)
Hmm, I don't want a workaround. I rather want a secure static binary with ASLR by default.

Discussion:
base.max_atomic_width = Some(64); base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-m64".to_string()); base.stack_probes = true; <ins> base.static_position_independent_executables = true; </ins> Ok(Target { llvm_target: "x86_64-unknown-linux-musl".to_string(),

<ins> -include ../../run-make-fulldeps/tools.mk # only-x86_64-unknown-linux-musl # How to manually run this # $ ./x.py test --target x86_64-unknown-linux-musl src/test/run-make/static-pie all: $(RUSTC) --target $(TARGET) -C target-feature=+crt-static test-aslr.rs # Check that no dynamic interpreter is set ! readelf -l $(call RUN_BINFILE,test-aslr) | $(CGREP) INTERP # Check that we have a dynamic executable readelf -l $(call RUN_BINFILE,test-aslr) | $(CGREP) DYNAMIC # Check for address space layout randomization $(call RUN,test-aslr) --test-aslr </ins>

<ins> const NUM_RUNS: usize = 10; fn run_self(exe: &str) -> usize { use std::process::Command; let mut set = std::collections::HashSet::new(); let mut cmd = Command::new(exe); cmd.arg("--report"); (0..NUM_RUNS).for_each(|_| { set.insert(cmd.output().expect("failed to execute process").stdout); }); set.len() } fn main() { let mut args = std::env::args(); let arg0 = args.next().unwrap(); match args.next() { Some(s) if s.eq("--report") => { println!("main = {:#?}", &main as *const _); } Some(s) if s.eq("--test-no-aslr") => { let cnt = run_self(&arg0); if cnt != 1 { eprintln!("FAIL: {} most likely ASLR", arg0); std::process::exit(1); } println!("PASS: {} does no ASLR", arg0); } Some(s) if s.eq("--test-aslr") => { let cnt = run_self(&arg0); if cnt != NUM_RUNS { eprintln!("FAIL: {} most likely no ASLR", arg0); std::process::exit(1); } println!("PASS: {} does ASLR", arg0); } Some(_) | None => { println!("Usage: {} --test-no-aslr | --test-aslr", arg0); std::process::exit(1); } } } </ins>
Change:
The compiler seems unable to determine that two types are equal. I tried this code: I expected the program to compile and run without issue, because is , so the call should be fine. Instead, I got this error message: The problem exists on stable 1.42 and nightly 1.44
It somehow compiles if you replace the associated type with a type parameter:
cc /
Possibly relevant rustc log entries: Seems like the will resolve the inference variable to yield , but for some reason is unable to normalize that further.
It seems like the opaque type has a substs with only in it; on first glance I'd have expected the projection there, but the docs on do explain this: So it seems like the is what was inserted for the type parameter, making . I'm not sure why this is represented like it is, but it seems like we need more info to be able to look at the real substs of the opaque type.
Duh, I forgot how opaque types work. Not sure where would be stored (? It's empty at this point according to log), but it's definitely not in the type, so this output makes sense.
This is fixed on nightly.

Discussion:
<ins> // check-pass trait Factory { type Product; } impl Factory for () { type Product = (); } trait ProductConsumer<P> { fn consume(self, product: P); } impl<P> ProductConsumer<P> for () { fn consume(self, _: P) {} } fn make_product_consumer<F: Factory>(_: F) -> impl ProductConsumer<F::Product> { () } fn main() { let consumer = make_product_consumer(()); consumer.consume(()); } </ins>
Change:
After and , rustc is ready to use LLVM completely threadsafely. All that's missing is to the and flags to LLVM's configure script. Once this is done, the should be uncommented as well. This is a simple change, but requires the bots to rebuild LLVM (which has caused problems in the past). has some other LLVM patches to integrate, and this would fit nicely with those.
and are closed now, so this should be ready to be closed as well. I'm not sure what the problems are with the bots rebuilding LLVM ( so I'm a bit hesitant to try it myself. I'd like this to be fixed so I can re-enable the rustpkg tests, though.
I just opened a pull request () to actually stop passing this option to configuring LLVM. The problem is that this doesn't trigger an LLVM rebuild, so once the change has gone through the bots need to have their llvm checkout cleaned before landing the further improvements (uncommenting that block of code to enable a threadsafe rustc)
We can try running the bots with after that patch lands, but I don't know if it works. Without graydon I think we can at least manually clean the windows, mac, and bsd bots.

Discussion:
LLVM_TARGET="--target=$t" # Disable unused LLVM features <del> LLVM_OPTS="$LLVM_DBG_OPTS --disable-docs  --enable-bindings=none --disable-threads  --disable-pthreads" </del> <ins> LLVM_OPTS="$LLVM_DBG_OPTS --disable-docs --enable-bindings=none" </ins> case "$CFG_C_COMPILER" in ("ccache clang")