jiebi/CodeConvo huggingface dataset:
Change:
for after.each |&elt| { check_pat(pcx, elt, ty::mk_err()); } <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { fmt!("mismatched types: expected `%s` but found %s", resolved_expected, actual)}, ~"a vector pattern", None); </del> <ins> fcx.infcx().type_error_message_str_with_expected( pat.span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), ~"a vector pattern", None); </ins> fcx.write_error(pat.id); return; }

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
/// /// There is a small difference between the two: the `derive` strategy will also place a `Copy` /// bound on type parameters, which isn't always desired. <del> /// /// ## When can my type _not_ be `Copy`? /// /// Some types can't be copied safely. For example, copying `&mut T` would create an aliased /// mutable reference, and copying `String` would result in two attempts to free the same buffer. /// /// Generalizing the latter case, any type implementing `Drop` can't be `Copy`, because it's /// managing some resource besides its own `size_of::<T>()` bytes. /// /// ## When should my type be `Copy`? /// /// Generally speaking, if your type _can_ implement `Copy`, it should. There's one important thing /// to consider though: if you think your type may _not_ be able to implement `Copy` in the future, /// then it might be prudent to not implement `Copy`. This is because removing `Copy` is a breaking /// change: that second example would fail to compile if we made `Foo` non-`Copy`. /// /// # Derivable /// /// This trait can be used with `#[derive]`. </del> #[stable(feature = "rust1", since = "1.0.0")] #[lang = "copy"] pub trait Copy : Clone {

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
- name: ensure line endings are correct run: src/ci/scripts/verify-line-endings.sh if: success() && !env.SKIP_JOB <ins> - name: ensure backported commits are in upstream branches run: src/ci/scripts/verify-backported-commits.sh if: success() && !env.SKIP_JOB </ins> - name: run the build run: src/ci/scripts/run-build-from-ci.sh env:

Discussion:
The 1.45.1 release is primarily being made because of the accidental omission of a rustfmt backport from the 1.45 beta branch after it landed in 1.44.1. The release team discussed this today, and we'd like to implement some automation to try and prevent this in the future at relatively low cost. The plan is to only allow landing commits in beta / stable branches if (or similar, but that seems like the right thing) indicates they've already landed in the preceding branches (beta and master for stable, just master for beta). We will also want an explicit set of commits that are just allowed. This will slightly increase the work needed during beta backports, as this list will need updating if there are any merge conflicts at least -- but since backports are rare and usually rollups, this shouldn't be much of a problem hopefully. We would be interested in seeing someone implement this functionality! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error: this code is interpreted as a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:3:22 | LL |   const FOO: [u8; 3] = { |  ______________________^ LL | |     1, 2, 3 LL | | }; | |_^ | = note: to define an array, one would use square brackets instead of curly braces help: try using [] instead of {} | LL ~ const FOO: [u8; 3] = [ LL |     1, 2, 3 LL ~ ]; | error: this code is interpreted as a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:7:24 | LL | const BAR: [&str; 3] = {"one", "two", "three"}; |                        ^^^^^^^^^^^^^^^^^^^^^^^ | = note: to define an array, one would use square brackets instead of curly braces help: try using [] instead of {} | LL | const BAR: [&str; 3] = ["one", "two", "three"]; |                        ~                     ~ error: this code is interpreted as a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:11:5 | LL |     {1, 2, 3}; |     ^^^^^^^^^ | = note: to define an array, one would use square brackets instead of curly braces help: try using [] instead of {} | LL |     [1, 2, 3]; |     ~       ~ error: expected one of `.`, `;`, `?`, `}`, or an operator, found `,` --> $DIR/issue-87830-try-brackets-for-arrays.rs:16:6 | LL |     1, 2, 3 |      ^ expected one of `.`, `;`, `?`, `}`, or an operator error: aborting due to 4 previous errors </ins>

Discussion:
I ended up spending way too much time debugging the following error, since I was trying to port some C code to rust. Give the error: The error message is very vague and hard to determine the actual error here. Seeing as though some programming languages like Java and C use for arrays, I think it'd make sense for the compiler to suggest using if the user is trying to create an array. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suppose adding manual diagnostic somewhere around will get the job done. claim
Change:
/// assert_eq!(vec![1, 2, 3], *shared); /// ``` #[inline] <del> fn from(v: Vec<T>) -> Rc<[T]> { match Rc::try_from_vec_in_place(v) { Ok(rc) => rc, Err(mut v) => { unsafe { let rc = Rc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc } } </del> <ins> fn from(mut v: Vec<T>) -> Rc<[T]> { unsafe { let rc = Rc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc </ins> } } }

Discussion:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely.

The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.
Change:
<ins> // build-pass // compile-flags: --crate-type lib -C opt-level=0 // Regression test for LLVM crash affecting Emscripten targets pub fn foo() { (0..0).rev().next(); } </ins>

Discussion:
On current num-integer master (commit ), rustc nightly and beta both crash when targeting . Stable is fine. (The inline attribute warning is irrelevant to success/failure, but I'll clean that up separately.) cc rust-num/num-integer
<details<summaryGDB backtrace of the SIGSEGV thread on nightly:</summary</details
Thanks Minimal reproducible test case:
triage: P-high for now. (but this is a Tier-2 target, so it may get downgraded to P-medium after a few weeks. We will see.)
cc -- the versions correspond to the LLVM change for emscripten.
This looks like an error in the LLVM verifier, so there is something wrong with the generated LLVM IR. I think we can rule out a bug in the WebAssembly LLVM backend.
Sorry I'm not sure where this would be coming from either.. It's likely due to the upgrade of LLVM for the emscripten target for sure though
Hello, Is there an ETA for the fix? Or maybe someone more familiar with the issue could guide me on where/how this can be fixed, so I can try on my own if it's not part of the roadmap yet?
This is on my backlog of things to look into, but I don't know when I will be able to get to it. I don't know of anyone else planning to look into it.
It looks like this affects as well:
tested the minimum test case (above) on wasm32-unknown-emscripten using stable (1.40.0 2019-12-16) and nightly (1.42.0 - 2020-01-01) with the same result: Called function must be a pointer! call addrspace() void &lt;badref(i8* %40), !dbg !52 in function ZN4core4iter5range116implu20u20AGT$9nextback17h9348d20e8f4fe0bcE LLVM ERROR: Broken function found, compilation aborted!
I started looking into this and I can successfully reproduce the crash. On some runs I get additional errors where the junk string is nondeterministic. Sometimes I also get the message . Clearly there is a memory corruption issue. Is there a way to build rustc and its LLVM with AddressSanitizer enabled?

It looks like this is a use-after-free when LLVM is built in release mode. It is caught earlier by an assertion with a debug build of LLVM, and from the backtrace there it looks like there is indeed a previously-unknown issue with the Emscripten exception lowering pass. We are investigating further now.
Fix in LLVM incoming: Once it merges upstream, I will handle getting it merged to Rust's LLVM fork and from there to rustc.
Should be fixed by
Were you able to verify that? I can still reproduce it with .
No, I just checked that the patch had landed. Reopening.
I thought it had been fixed because the regression test I had locally for it passes. But it turns out the test runner uses by default and the crash now needs to be triggered. I will continue looking into this.
Confirmed, thanks!
Change:
f.debug_struct("Key").finish_non_exhaustive() } } impl<T> Key<T> { pub const fn new() -> Key<T> { Key { inner: LazyKeyInner::new(), dtor_state: Cell::new(DtorState::Unregistered) }

Discussion:
Miri detects UB when running the following program: With and With
I see the bug. We have (which means fns in std automatically trap aborts) but that doesn't apply to functions which are present in the macro expansion (some of which can't really be moved outside the macro). Ill fix in like an hour or two. We just need to guard panics in a couple places. In practice I think this should not call problems and we'd just hit an abort guard in an defined in a few frames up, although perhaps that's not true in 100% of cases (I can update on this once I implement the fix).
The is that the fix to this may need to be backported thus I am tagging this with P-high.
the fix was merged and a backport was rejected:
Change:
--init  --rm  rust-ci  <del> $command </del> <ins> "${command[@]}" </ins> cat $objdir/${SUMMARY_FILE} >> "${GITHUB_STEP_SUMMARY}"

Discussion:
I have this totally normal config: Then I want to run Then inside the container, Bootstrap is compiled, but then emits this: My repository history is not too shallow. The only way to use the CI scripts seems to be to set . The reason download-ci-llvm doesn't work seems to be the ownership of the mount: So maybe this is an easy fix? Can we just run that somewhere? It seems to work, I'm just not sure where it would be run.
That script should set the uid of the processes inside the container to match what you use outside of the container and thus who owns the source repo: If you use podman, are you maybe using a version of podman which doesn't contain the literal string in ? And can you run outside and inside the container?
I am not using Podman
Outside the container: After
I assume this is related with your docker privileges (the user group assigned on docker). Can't reproduce this on my side.
That seems reasonable? What should that be instead?
should be able to handle this
That's very nice of you, but if I have a scuffed Docker setup on my dev machine I'd like to know in what way it's scuffed if you don't mind :sweat_smile:
By default, docker runs under root mode, and I believe this is the main issue here. On the other hand, podman runs in rootless mode by default: I was able to reproduce the problem by running podman under root privileges. I believe the problem here is more related to the nature of docker rather than an issue with your docker setup.
The snippet I mentioned in should ensure that the programs inside the container run as the same user as the one with which was invoked.
And when the user is root (e.g., running the script with root user), you get .
Change:
// @has deprecated_future_staged_api/index.html '//*[@class="stab deprecated"]'  //      'Deprecation planned' // @has deprecated_future_staged_api/struct.S2.html '//*[@class="stab deprecated"]'  <del> //      'Deprecating in a future Rust version: literally never' </del> <ins> //      'Deprecating in a future version: literally never' </ins> #[deprecated(since = "TBD", note = "literally never")] #[stable(feature = "deprecated_future_staged_api", since = "1.0.0")] pub struct S2;

Discussion:
says "Deprecating in a future Rust version" ! but it will not be deprecated in a future Rust version, it will be deprecated in a future crate version. An easy fix would be just always saying "version" instead of "Rust version", alternatively special casing the standard library.
Change:
// Crate that exports a const fn. Used for testing cross-crate. <ins> #![feature(const_fn)] </ins> #![crate_type="rlib"] <del> pub const fn foo() -> usize { 22 } //~ ERROR const fn is unstable </del> <ins> pub const fn foo() -> usize { 22 } pub const fn bar() -> fn() { fn x() {} x } #[inline] pub const fn bar_inlined() -> fn() { fn x() {} x } #[inline(always)] pub const fn bar_inlined_always() -> fn() { fn x() {} x } </ins>

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
<ins> // check-pass #![feature(trait_alias)] trait Bounded { const MAX: Self; } impl Bounded for u32 { // This should correctly resolve to the associated const in the inherent impl of u32. const MAX: Self = u32::MAX; } trait Num = Bounded + Copy; fn main() {} </ins>

Discussion:
When a trait alias to a trait with a method with the same name as a method on a struct is in scope, rustc is suddenly unable to disambiguate the trait method from the struct method.
cc
cc and -- Is importing the trait with higher priority than inherent items?
Is importing the trait with higher priority than inherent items? It shouldn't do that, looks like a bug. A method introduced into scope via trait alias (import) should behave identically to methods introduced with a trait (import), that means lower priority than inherent items.
Change:
<ins> #![feature(test)] extern crate test; #[test] fn short_test_name() {} #[test] fn this_is_a_really_long_test_name() {} #[bench] fn short_bench_name(b: &mut test::Bencher) { b.iter(|| 1); } #[bench] fn this_is_a_really_long_bench_name(b: &mut test::Bencher) { b.iter(|| 1); } </ins>

Discussion:
libtest output recently started indenting some but not all test results: Seems like benchmarks are indented but regular tests are not.
Cc any idea which change might have caused this? I think this must be fairly recent but haven't tried bisecting yet.
Is this still reproducable?
With this can no longer be tested using x.py, since bootstrap now does test output formatting itself. So this now needs a little cargo project with a test and a benchmark, to check what libtest actually does.
It is because benches are dynamic, and they always use padding (and tests are static): I'm not sure why padding is different for static vs dynamic. Here is a repro:
Seems like that could use context if the bench is only being run as a test, then don't pad. The padding is desirable for benchmark output so the numeric values line up, for easier visual comparison. You could argue either way about tests -- maybe ok/FAILED would stand out even more with padded alignment.
PR with regression tests and a fix (in that order):
Change:
<ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-51431.rs:7:32 | LL |         asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} |                                ^^^^ error: aborting due to previous error </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.
Change:
true  => flt2dec::Sign::MinusPlus, }; <del> let mut buf = [0; 1024]; // enough for f32 and f64 let mut parts = [flt2dec::Part::Zero(0); 16]; let formatted = if let Some(precision) = fmt.precision { </del> <ins> if let Some(precision) = fmt.precision { </ins> // 1 integral digit + `precision` fractional digits = `precision + 1` total digits <del> flt2dec::to_exact_exp_str(flt2dec::strategy::grisu::format_exact, *num, sign, precision + 1, upper, &mut buf, &mut parts) </del> <ins> float_to_exponential_common_exact(fmt, num, sign, precision + 1, upper) </ins> } else { <del> flt2dec::to_shortest_exp_str(flt2dec::strategy::grisu::format_shortest, *num, sign, (0, 0), upper, &mut buf, &mut parts) }; fmt.pad_formatted_parts(&formatted) </del> <ins> float_to_exponential_common_shortest(fmt, num, sign, upper) } </ins> } macro_rules! floating {

Discussion:
floattodecimalcommon in does this: let mut buf = [0; 1024]; let mut parts = [flt2dec::Part::Zero(0); 16]; and then passes buf and parts to flt2dec::toexactfixedstr or flt2dec::toshorteststr Looking at the docs for those functions at and the "parts" array needs to have length at least 5, right? And the "buf" array needs to be at least 800+ for the toexactfixedstr case but only 17 (MAXSIGDIGITS) for the toshorteststr case, afaict. Changing the toshorteststr case to not use the huge buffer would probably help out too. Also, it's not clear to me that the "buf" scratch buffer needs to be zero-initialized. Does it?
Note that I'm poking at this a bit.
I spun off the zeroing thing into because I have a fix for that... we may still want to make the stackframe here smaller, though.
Change:
[IdentLike(_), Punct('+' | '-')] | // 1e+2 | 1e-2 [IdentLike(_), Punct('+' | '-'), IdentLike(_)] | <ins> // 1.2e+ | 1.2e- [IdentLike(_), Punct('.'), IdentLike(_), Punct('+' | '-')] | </ins> // 1.2e+3 | 1.2e-3 [IdentLike(_), Punct('.'), IdentLike(_), Punct('+' | '-'), IdentLike(_)] => { // See the FIXME about `TokenCursor` above.

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Affected versions: probably all versions since that panic was introduced, I tried nightly 2021-11-07 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsA quick inspection of the code shows that the similar case is handled the same as : So if I had to guess I would say that the match is missing this one case, so should be handled the same as : But no idea what does that code even do, it has a FIXME by so maybe he knows better. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
let mut encoder = PrettyEncoder::new(writer); animal.encode(&mut encoder).unwrap(); }), <del> " [n   "Frog",n   "Henry",n   349n ]".to_string() </del> <ins> "{n   "variant": "Frog",n   "fields": [n     "Henry",n     349n   ]n }".to_string() </ins> ); }

Discussion:
Encoding an enum field with the pretty encoder results in an ExpectedError when decoding. In emitenumvariant of the pretty encoder, "variants" and "fields" need to be to behave the same way as the normal encoder.
Do you have a simple test case?
Taking a look
Closed by
Thank you for fixing this!