jiebi/CodeConvo huggingface dataset:
Code change:
TyKind::Path(ref qself, ref path) => { self.diagnostic_metadata.current_type_path = Some(ty); self.smart_resolve_path(ty.id, qself.as_ref(), path, PathSource::Type); <ins> // Check whether we should interpret this as a bare trait object. if qself.is_none() && let Some(partial_res) = self.r.partial_res_map.get(&ty.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { // This path is actually a bare trait object.  In case of a bare `Fn`-trait // object with anonymous lifetimes, we need this rib to correctly place the // synthetic lifetimes. let span = ty.span.shrink_to_lo().to(path.span.shrink_to_lo()); self.with_generic_param_rib( &[], NormalRibKind, LifetimeRibKind::Generics { binder: ty.id, kind: LifetimeBinderKind::PolyTrait, span, }, |this| this.visit_path(&path, ty.id), ); self.diagnostic_metadata.current_type_path = prev_ty; return; } </ins> } TyKind::ImplicitSelf => { let self_ty = Ident::with_dummy_span(kw::SelfUpper);

Related discussion:
text: ndarray 0.9.1 compiles with rustc 1.61.0 but not with rustc 1.64.0-nightly ( 2022-06-27). Put this into a of a new project: rustc stable <= 1.61.0 compiles the crate fine, rustc nightly gives the following error: modify labels: +regression-from-stable-to-nightly -regression-untriaged
Just adding a note. The issue seems to be an old version of that used to use back in v0.9.1 <details</detailsThe crate from v0.13.0 (released in sept. 2019) compiles fine also on latest Rust nightly
bisection seems to point to commit cc searched nightlies: from nightly-2022-04-01 to nightly-2022-06-28 regressed nightly: nightly-2022-06-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details(unsure if this regression may hit other more recent crates)
I've been suspecting this bug for a few days, but unable to reproduce it. I think I have a patch, will confirm once I manage to MCVE.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
<ins> error[E0382]: use of moved value: `t` --> $DIR/issue-67123.rs:2:13 | LL | fn foo<T>(t: T) { |        - help: consider restricting this bound: `T: Copy` LL |     || { t; t; }; |          -  ^ value used here after move |          | |          value moved here | = note: move occurs because `t` has type `T`, which does not implement the `Copy` trait error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>

Related discussion:
text: I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be
Code change:
// There was a previous subslice pattern; make sure we don't allow more. let rest_span = match pat.kind { PatKind::Rest => Some(pat.span), <del> PatKind::Ident(.., Some(ref sub)) if sub.is_rest() => { // The `HirValidator` is merciless; add a `_` pattern to avoid ICEs. after.push(self.pat_wild_with_node_id_of(pat)); </del> <ins> PatKind::Ident(ref bm, ident, Some(ref sub)) if sub.is_rest() => { // #69103: Lower into `binding @ _` as above to avoid ICEs. after.push(lower_rest_sub(self, pat, bm, ident, sub)); </ins> Some(sub.span) } _ => None,

Related discussion:
text: The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:
Code change:
// in `SpecialCasing.txt`, // so hard-code it rather than have a generic "condition" mechanism. // See https://github.com/rust-lang/rust/issues/26035 <del> let out_len = self.len() - rest.len(); let sigma_lowercase = map_uppercase_sigma(&self, i + out_len); </del> <ins> let sigma_lowercase = map_uppercase_sigma(self, prefix_len + i); </ins> s.push(sigma_lowercase); } else { match conversions::to_lower(c) {

Related discussion:
text: I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.
Code change:
// in `SpecialCasing.txt`, // so hard-code it rather than have a generic "condition" mechanism. // See https://github.com/rust-lang/rust/issues/26035 <del> let out_len = self.len() - rest.len(); let sigma_lowercase = map_uppercase_sigma(&self, i + out_len); </del> <ins> let sigma_lowercase = map_uppercase_sigma(self, prefix_len + i); </ins> s.push(sigma_lowercase); } else { match conversions::to_lower(c) {

Related discussion:
text: The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.
Code change:
install_fatal_error_handler(FatalErrorHandler); } <ins> extern "C" void LLVMRustDisableSystemDialogsOnCrash() { sys::DisableSystemDialogsOnCrash(); } </ins> extern "C" char *LLVMRustGetLastError(void) { char *Ret = LastError; LastError = nullptr;

Related discussion:
text: The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.
Code change:
// We special case `#[derive(_)]n` and other attribute suggestions, because those // are the ones where context is most useful. let file_lines = sm <del> .span_to_lines(span.primary_span().unwrap().shrink_to_hi()) </del> <ins> .span_to_lines(parts[0].span.shrink_to_hi()) </ins> .expect("span_to_lines failed when emitting suggestion"); let line_num = sm.lookup_char_pos(parts[0].span.lo()).line; if let Some(line) = file_lines.file.get_line(line_num - 1) {

Related discussion:
text: <!-- 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 the following code, split into two files: This code, as expected, produces , shown below. However, the help message at the bottom of the error appears to be referencing line 2 in , while displaying the filename , thus suggesting we add the annotation to a comment in . It should instead point to the in . <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The issue is that in , the span we use to look up the file/line mapper is the primary span of the message, i.e. the error in
Code change:
<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>

Related discussion:
text: I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>

Related discussion:
text: produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>

Related discussion:
text: <!-- 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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>

Related discussion:
text: <!-- 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
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":
Code change:
[[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Related discussion:
text: Minimal reproducible example, targeting the STM32G030F6 microcontroller: This panics in the computation of when built with: Note: this had to be tested with in the dev profile, in order to fit on the small flash size on the chip. This was confirmed on the and toolchains. <details<summaryGDB backtrace at the panic</summary</details<details<summaryFull to build</summary</details<details<summarymemory.x for the STM32G030F6</summary</details
Would it be possible to provide the output for this test case?
This is inside compiler-builtins. The arguments in the stack trace seem all sorts of wrong all over the place, though. But the shift width passed into is what you'd expect. An ABI mismatch, maybe?
To elaborate on my remark above: the LLVM IR will only reveal a plain instruction, which becomes a libcall only in codegen. To the issue author: can you please also post the exact command you're building? I'm not able to reproduce a similar issue when using a based approach – in particular I see many more functions being inlined away, functions which in your case don't appear to be. This is what I was trying:
Cortex-M0+ uses , which is also shipped via rustup
Hm, I cannot reproduce inside QEMU (using , steps described below), but maybe I'm missing something (maybe the error only shows up on the real hardware and not in QEMU). Please correct me, if I'm wrong. <details<summaryReproduction</summary</details
Sorry, I will put together a package that fully demonstrates it and upload a tarball later today. I'll also provide the LLVM and executable output. To be clear, I wasn't building using any direct invocation of rustc, just with cargo.
So I managed to simplify the minimal example further a bit, as it turns out that simply panics too, since the formatter for integers involves multiplication. This is reflected in the following attachments. I have tested these on a live STM32G030 chip; the GDB backtrace is from that (over openocd through the SWD port). I don't consider myself knowledgable enough with QEMU to try to reproduce it there.
Code change:
[[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Related discussion:
text: Complete example: Executable: <details<summaryGDB backtrace at panic</summary</details<details<summaryLLVM IR</summary</details
does it also reproduce on Rust stable (or beta)? Just to understand here if it's a regression or this issue has "always" been here (I suspect the latter)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Good thinking... I just tested it on stable and it appears to not be present there (or at least not with all else equal). I confirmed the issue on again just to be sure I didn't change anything else. I'm not sure if there's a good way to bisect the rust toolchain to find the regression? If there is I may be able to script it to see if GDB reports a panic and use that. Of course QEMU would be better-suited for that, so I may try to repro in it as well.
cool then probably we can try to find the regression To bisect we use , it will download nightlies in a range of time and bisect them to find where the regression starts. You'll need to download the Rust sources beforehand (this repo) and then run it like: should be 755 and something like: cargo-bisect will then download nightlies. The first one must not reproduce the issue, so if it does, move a bit back in time until you hit one of the last good nightly. If everything goes well you should get an ouput similar to Thanks a lot for trying to bisect the issue! :-) label regression-from-stable-to-nightly
Here's the report: searched nightlies: from nightly-2021-04-01 to nightly-2021-06-05 regressed nightly: nightly-2021-05-15 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
That is a huge commit, but if it helps, I have a hunch that the regression may actually be in , since a) the version of it changed as part of that commit and b) that's where the implementaiton of this is.
Code change:
[[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Related discussion:
text: On the other hand, the connection to is weird. Before reporting the issue I did delve into the source but most of the arithmetic implementation stuff kinda went over my head unfortunately.
This is highly likely to slip into stable next week -- let's ping arm to at least get some more eyes on it (doesn't look like that was done yet).
Error: Parsing ping command in failed: ...'t ping arm' ' to at lea'... Please let know if you're having trouble with this bot.
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I can reproduce this on qemu. I'm not sure precisely what I'm doing differently to but I'm using the source tarball uploaded (plus a modified memory layout for the QEMU machine). Possibly in the cargo config would do it. From the last working rust commit bumping compiler-builtins to 0.1.40 (from 0.1.39) is enough to trigger this. Unfortunately, patching out compilerbuiltins to a local path (checked out to 0.1.39) also seems to reliably trigger it so I haven't been able to narrow down to a specific compilerbuiltins commit. Additionally I can't reproduce on , only v6.
That matches what I observed on real hardware as well.
54 stable will be built today and released on Thursday, this will unfortunately have to slip into stable :( The target is not tier 1 so this won't block the release, but it will be in the compatibility notes section.
Is the build process documented somewhere? Is it a highly optimized binary?
The build itself is done by our normal CI and the full release process is . The build doesn't take that long to finish though. The Release Team prepares the final release on Monday to be able to publish a pre-release on Monday evening, allowing testing from the wider community before the actual release goes out. It's possible to do a rebuild after Monday if critical issues are found and need to be fixed, but is not a Tier 1 target so a fix for this would likely not result in a rebuild, and would slip into 1.55.
Thanks!
Code change:
[[package]] name = "compiler_builtins" <del> version = "0.1.47" </del> <ins> version = "0.1.49" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "fd4ed89e0a5c3e50b15c0045fbe1ff8567b703bc07544faf935ddff0aaa7b65f" </del> <ins> checksum = "20b1438ef42c655665a8ab2c1c6d605a305f031d38d9be689ddfef41a20f3aa2" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Related discussion:
text: I noted that the python scripts use the aws cli instead of the excellent boto3 library. But probably the scripts are battle proof by now.
This is a bug in LLVM's expansion of 128-bit shifts: The 128-bit shift is expanded to a series of 64-bit shift via . Note how the shift value in is only masked with before being passed to . This means that the shift value passed to may be larger than 64, which is UB according to the specification for (shift value must be < 64).
A bisect on compiler-builtins leads to this commit as the incidental "cause": Reverting it does fix this bug if a quick & dirty fix is wanted.
On second thought, I don't think this is an LLVM bug: it seems that the code calls with an out-of-range shift, but then doesn't actually use the result of that call in that case. I opened which should fix this, could someone test to see if this actually resolves the issue?
looks fixed to me. Nice work!