jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: type parameter `T` is part of concrete type but not used in parameter list for the `impl Trait` type alias --> $DIR/issue-53598.rs:20:42 | LL |       fn foo<T: Debug>(_: T) -> Self::Item { |  __________________________________________^ LL | | LL | |         S::<T>(Default::default()) LL | |     } | |_____^ error: aborting due to previous error </ins>

Discussion:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by
Change:
<ins> // build-pass #![feature(const_generics)] #![allow(incomplete_features)] fn works() { let array/*: [u8; _]*/ = default_byte_array(); let _: [_; 4] = array; Foo::foo(&array); } fn didnt_work() { let array/*: [u8; _]*/ = default_byte_array(); Foo::foo(&array); let _: [_; 4] = array; } trait Foo<T> { fn foo(&self) {} } impl Foo<i32> for [u8; 4] {} impl Foo<i64> for [u8; 8] {} // Only needed because `[u8; _]` is not valid type syntax. fn default_byte_array<const N: usize>() -> [u8; N] where [u8; N]: Default, { Default::default() } fn main() { works(); didnt_work(); } </ins>

Discussion:
I've come up with this example (): My understanding is that the error is caused by the obligation being on just (which means it's not retried when is unified with ), whereas it should be stalled on both and so that it's retried when either changes. Right now is limited to type inference variables, so its representation will need to change, and will need to expose constants too. I believe ran into this as well, but for WF obligations, not trait ones. I'm self-assigning this because I'm working on the fix (as part of a larger effort). cc
Note to self: the PR fixing this should also test this example (): The reason for this is that this second example has the type and const inference variables in different generic args of , meaning fixing it also requires changing this to :
I've definitely noticed problems with inference involving consts before, but wasn't able to pin down where the issue was stemming from. It would be great if this could be addressed once and for all.
Change:
use crate::core::config::{Config, TargetSelection}; use crate::utils::channel; use crate::utils::helpers::{self, exe, get_clang_cl_resource_dir, output, t, up_to_date}; <del> use crate::{CLang, GitRepo, Kind}; </del> <ins> use crate::{generate_smart_stamp_hash, CLang, GitRepo, Kind}; </ins> use build_helper::ci::CiEnv; use build_helper::git::get_git_merge_base;

Discussion:
I tried this code: I expected to see this happen: bootstrap rebuilds LLVM, since it's changed. Instead, this happened: bootstrap does nothing. The problem is that we 're using a stamp file and assume that if the commit hasn't changed then none of the files have changed either: I am not sure why we do that? Are we assuming that CMake rebuilds too frequently? That seems like something we should fix upstream ... cc I think this would make your lives easier. HEAD is branched from .
hmm, looks related. I am not sure why that would be the correct behavior? If CFLAGS has changed we should rebuild; I would expect distros to make sure CFLAGS matches between invocations of bootstrap.
The stamp checking for the "normal" case, when not building from a source tarball, has been there since the initial commit of bootstrap:
Are you trying to address the git "dirty" case, or the non-git case, or both?
Both, but primarily the git case since that's how most people are developing I think.
Ok, I agree the git case is where folks may actually be making changes, and I still think it's ok not to automatically "notice" changes in the non-git case. LLVM is big enough that checking for dirty git may not be cheap though. On my Linux system with NVME, it takes ~0.5s after dropping page caches, and ~0.15s cached. On systems with slower disks, virus scanners, etc., it may be a lot worse.
Yeah, I don't think this is particularly important. The main issue with making changes to LLVM is , which prevents the change from being picked up even if you do commit it.
Change:
#[derive(RustcDecodable, Default, Clone)] struct Install { prefix: Option<String>, <ins> mandir: Option<String>, docdir: Option<String>, libdir: Option<String>, </ins> } /// TOML representation of how the LLVM build is configured.

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
// Transforms a ty:Ty for being encoded and used in the substitution dictionary. It transforms all // c_void types into unit types unconditionally, and generalizes all pointers if // TransformTyOptions::GENERALIZE_POINTERS option is set. <ins> #[instrument(level = "trace", skip(tcx))] </ins> fn transform_ty<'tcx>(tcx: TyCtxt<'tcx>, ty: Ty<'tcx>, options: TransformTyOptions) -> Ty<'tcx> { let mut ty = ty;

Discussion:
I've got a fix for this that I'll be uploading in a minute or two, I'm filing the issue to claim an issue number for the test. : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This seems to be a duplicate of .
Change:
<del> use crate::error::TranslateError; </del> <ins> use crate::error::{TranslateError, TranslateErrorKind}; </ins> use crate::snippet::Style; use crate::{DiagnosticArg, DiagnosticMessage, FluentBundle}; use rustc_data_structures::sync::Lrc;

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.
Change:
} } (Ok(const_int(a)), Ok(const_int(b))) => { <del> let is_a_min_value = |&:| { </del> <ins> let is_a_min_value = || { </ins> let int_ty = match ty::expr_ty_opt(tcx, e).map(|ty| &ty.sty) { Some(&ty::ty_int(int_ty)) => int_ty, _ => return false

Discussion:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in
Change:
<ins> error: unexpected close delimiter: `}` --> $DIR/mismatched-delim-brace-empty-block.rs:5:1 | LL |   fn main() { |  ___________- LL | | LL | | } | |_- this block is empty, you might have not meant to close it LL |       let _ = (); LL |   } |   ^ unexpected close delimiter error: aborting due to previous error </ins>

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
<ins> // build-pass // compile-flags: --crate-type=lib use std::marker::PhantomData; pub trait StreamOnce { type Token; } impl StreamOnce for &str { type Token = (); } pub trait Parser<Input: StreamOnce> { type PartialState: Default; fn parse_mode(&self, _state: &Self::PartialState) {} fn parse_mode_impl() {} } pub fn parse_bool<'a>() -> impl Parser<&'a str> { pub struct TokensCmp<C, Input> where Input: StreamOnce, { _cmp: C, _marker: PhantomData<Input>, } impl<Input, C> Parser<Input> for TokensCmp<C, Input> where C: FnMut(Input::Token), Input: StreamOnce, { type PartialState = (); } TokensCmp { _cmp: |_| (), _marker: PhantomData } } pub struct ParseBool; impl<'a> Parser<&'a str> for ParseBool where &'a str: StreamOnce, { type PartialState = (); fn parse_mode_impl() { parse_bool().parse_mode(&Default::default()) } } </ins>

Discussion:
https://crater-
searched nightlies: from nightly-2023-01-24 to nightly-2023-03-30 regressed nightly: nightly-2023-02-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis looks related to , but wasn't fixed by
Let's notify the people involved in that bisection, it's cc author and reviewer A minimization would be helpful.
probably just allowed another existing bug to show up, like the other projection issues. I've reduced the regression to this it still depends on , if anyone has the time to also remove that.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This seems to have disappeared in nightly. Bisect points to Maybe fixed by
Wasn't that PR already present in your previous bisection up to nightly-2023-03-30 ?
Ah, looks like the is fixed in , but not the .
label -E-needs-mcve +S-has-mcve
Change:
use rustc_errors::{pluralize, struct_span_err, Diagnostic, ErrorGuaranteed}; use rustc_macros::{SessionDiagnostic, SessionSubdiagnostic}; use rustc_span::source_map::Spanned; <del> use rustc_span::symbol::{kw, Ident}; </del> <ins> use rustc_span::symbol::{kw, sym, Ident}; </ins> use rustc_span::{Span, SpanSnippetError, DUMMY_SP}; use std::ops::{Deref, DerefMut};

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
let def_id = instance.def_id(); let containing_scope = get_containing_scope(self, instance); let loc = self.lookup_debug_loc(span.lo()); <del> let file_metadata = file_metadata(self, &loc.file.name, def_id.krate); </del> <ins> let file_metadata = file_metadata(self, &loc.file, def_id.krate); </ins> let function_type_metadata = unsafe { let fn_signature = get_function_signature(self, fn_abi);

Discussion:
shows a pretty big regression between and . I don't know if this is expected, but I'm putting this out there in case others see the dent in perf charts and wonder what had happened. <hr/EDIT( we how have a for . , the other PR in the range, (but only for a small subset of runs).
cc
The range is so the candidates are: "Make the rustc respect the flag in incremental mode." "Add hash of source files in debug info" EDIT: oops, missed - so it's likely . Slow MD5 implementation? I'm curious, why does (merge commit for ) not have its own perf run? Is there a way to trigger one now?
is in the queue:
It looks like this was caused by . I'll start investigating why. I timed several compilations of locally in debug with and without .
For the record, from . I'll update the issue description to minimize potential confusion. Two things I'm seeing: are way worse regressions than , you can focus on the worse ones to get better contrast in measurements (e.g. even has "patched incremental" runs slowed down a lot, unlike many others, being another example I guess) detailed profile (if you click the percentage for a run) shows a lot of LLVM differences, e.g. for , and most of the regressions are , with effectively no ones, so I think we might be able to get away without a revert, just adding a flag controlling whether LLVM sees these hashes (assuming that's the source of the slowdown)
We have (), which at a glance looks right. looks like noise, and so does , so I believe this confirms the fix is complete. For the cost of MD5 hashing compared to SipHash, based on the changes to runs in the original regression, it looks insignificant.
Change:
RUN curl -sL https://nodejs.org/dist/v16.9.0/node-v16.9.0-linux-x64.tar.xz | tar -xJ ENV PATH="/node-v16.9.0-linux-x64/bin:${PATH}" <ins> ENV RUST_CONFIGURE_ARGS="--set rust.validate-mir-opts=3" </ins> # Install es-check # Pin its version to prevent unrelated CI failures due to future es-check versions. RUN npm install es-check@6.1.1 eslint@8.6.0 -g

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.
Change:
<ins> // Regression test for broken MIR error (#61442) // Due to the two possible evaluation orders for // a '+=' expression (depending on whether or not the 'AddAssign' trait // is being used), we were failing to account for all types that might // possibly be live across a yield point. #![feature(generators)] fn foo() { let _x = static || { let mut s = String::new(); s += { yield; "" }; }; let _y = static || { let x = &mut 0; *{ yield; x } += match String::new() { _ => 0 }; }; // Please don't ever actually write something like this let _z = static || { let x = &mut 0; *{ let inner = &mut 1; *{ yield (); inner } += match String::new() { _ => 1}; yield; x } += match String::new() { _ => 2 }; }; } fn main() { foo() } </ins>

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
Does this issue still occur? I couldn't reproduce it from given code on playground.
I just checked with nightly 2019-06-03, and it's still there. It requires the line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.
Change:
RUST_TARGET_PATH=. $(RUSTC) foo.rs --target=my-awesome-platform --crate-type=lib --emit=asm RUST_TARGET_PATH=. $(RUSTC) foo.rs --target=my-x86_64-unknown-linux-gnu-platform --crate-type=lib --emit=asm $(RUSTC) -Z unstable-options --target=my-awesome-platform.json --print target-spec-json > $(TMPDIR)/test-platform.json && $(RUSTC) -Z unstable-options --target=$(TMPDIR)/test-platform.json --print target-spec-json | diff -q $(TMPDIR)/test-platform.json - <ins> $(RUSTC) foo.rs --target=definitely-not-builtin-target 2>&1 | $(CGREP) 'may not set is_builtin' $(RUSTC) foo.rs --target=mismatching-data-layout </ins>

Discussion:
I'm new to Rust and I try to compile a project with a (I'm also new to that project and that project is not well organized.) when I use Makefile to make, the process of making executes and it reports it's a bug, so I'm here. I'm fresh here so if there is some information I don't provide, please tell me and I will try my best to provide it. Thank you! <!-- 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. --here I couldn't provide the example code since I don't really know the minimal set of code to be compiled the source code of the repo is in rustc should be in the nightly mode rust code is in the rust/sel4-rust/ in directory will execute in directory <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Thank you for filing an issue! When I click that linked you posted, I get an error. Is it set that other people can view it?
Sorry, I have fixed the typo. Now the link should be right.(next time I will be more careful to check my issue)
The root of the issue is in the target definition file that the repository contains, however there are three other bugs that can be fixed in rustc: should not ICE when invalid external targets are being used; should report the actual target name/file in the error message, not the LLVM target name; target files are allowed to set the property.
The minimal target file to reproduce: with
( is a 404 )
Change:
<ins> #!/bin/sh # Copyright 2016 The Rust Project Developers. See the COPYRIGHT # file at the top-level directory of this distribution and at # http://rust-lang.org/COPYRIGHT. # # Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or # http://www.apache.org/licenses/LICENSE-2.0> or the MIT license # <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your # option. This file may not be copied, modified, or distributed # except according to those terms. set -ex # We need to mitigate rust-lang/rust#34978 when compiling musl itself as well export CFLAGS="-fPIC -Wa,-mrelax-relocations=no" export CXXFLAGS="-Wa,-mrelax-relocations=no" MUSL=musl-1.1.14 curl https://www.musl-libc.org/releases/$MUSL.tar.gz | tar xzf - cd $MUSL CFLAGS="$CFLAGS -m32" ./configure --prefix=/musl-i686 --disable-shared --target=i686 make -j10 make install cd .. # To build MUSL we're going to need a libunwind lying around, so acquire that # here and build it. curl -L https://github.com/llvm-mirror/llvm/archive/release_37.tar.gz | tar xzf - curl -L https://github.com/llvm-mirror/libunwind/archive/release_37.tar.gz | tar xzf - # Whoa what's this mysterious patch we're applying to libunwind! Why are we # swapping the values of ESP/EBP in libunwind?! # # Discovered in #35599 it turns out that the vanilla build of libunwind is not # suitable for unwinding 32-bit musl. After some investigation it ended up # looking like the register values for ESP/EBP were indeed incorrect (swapped) # in the source. Similar commits in libunwind (r280099 and r282589) have noticed # this for other platforms, and we just need to realize it for musl linux as # well. # # More technical info can be found at #35599 cd libunwind-release_37 patch -Np1 < /build/musl-libunwind-patch.patch cd .. mkdir libunwind-build cd libunwind-build CFLAGS="$CFLAGS -m32" CXXFLAGS="$CXXFLAGS -m32" cmake ../libunwind-release_37  -DLLVM_PATH=/build/llvm-release_37  -DLIBUNWIND_ENABLE_SHARED=0 make -j10 cp lib/libunwind.a /musl-i686/lib </ins>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo