jiebi/CodeConvo huggingface dataset:
Change:
//! This module is responsible for installing the standard library, //! compiler, and documentation. <ins> use std::env; </ins> use std::fs; <del> use std::borrow::Cow; use std::path::Path; </del> <ins> use std::path::{Path, PathBuf, Component}; </ins> use std::process::Command; use Build;

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:
// check no error cascade let _ = main.f as *const u32; //~ ERROR attempted access of field <ins> let cf: *const Foo = &0; let _ = cf as *const [u8]; //~ ERROR vtable kinds let _ = cf as *const Bar; //~ ERROR vtable kinds </ins> }

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Lexer<'d>(&'d ()); impl Lexer<'d> { //~ ERROR use of undeclared lifetime name `'d` type Cursor = (); } fn test(_: Lexer::Cursor) {} fn main() {} </ins>

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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes
Change:
use super::CrateDebugContext; use rustc_hir::def_id::DefId; <del> use rustc_middle::ty::layout::LayoutOf; </del> <ins> use rustc_middle::ty::layout::{HasParamEnv, LayoutOf}; </ins> use rustc_middle::ty::{self, DefIdTree, Ty}; <del> use rustc_target::abi::Variants; </del> <ins> use tracing::trace; </ins> use crate::common::CodegenCx; use crate::llvm;

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. --glacier <!-- 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. --: Note: you need a build with rustc debug assertions enabled! <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// Here we want to prevent struct constructors from returning unsized types. // There were two cases this happened: fn pointer coercion in stable // and usual function call in presense of unsized_locals. <del> let output = tcx.erase_late_bound_regions(&fn_sig.output()); </del> <ins> // Also, as we just want to check sizedness, instead of introducing // placeholder lifetimes with probing, we just replace higher lifetimes // with fresh vars. let output = self.replace_bound_vars_with_fresh_vars( expr.span, infer::LateBoundRegionConversionTime::FnCall, &fn_sig.output()).0; </ins> self.require_type_is_sized_deferred(output, expr.span, traits::SizedReturnType); }

Discussion:
does not build on the current nightly because the compiler is unable to infer that a type is . This is a regression in the latest nightly. The line that errors is . Error message: Relevant commits: cc rust-lang-nursery/futures-rs
Minimized example without and external dependencies: .
Possibly caused by cc
Enabling the feature fixes this, so this is being caused by the gate .
Perhaps do I need some normalization before doing deferred ness checking?
triage. This is now a stable-to-beta regression. P-high.
assigning to to either r+ PR , come up with a new fix, or delegate those options to someone else.
Change:
extern crate consts; <ins> struct Defaulted; impl consts::AssocConst for Defaulted {} </ins> fn main() { <ins> let _ = Defaulted; </ins> match None { consts::SOME => panic!(), //~^ must be annotated with `#[derive(PartialEq, Eq)]`

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. --I don't have a reasonable sized reproducer yet. <!-- 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. --: Regression occurred ~between ..~ in () <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Updated the issue description with a complete backtrace that has full line info (435 frames deep!)
Update: I bisected this to () cc
it looks like this match needs to be updated somehow: Does this bug report contain enough information to understand the problem, or do you need an MCVE?
Could you reproduce but debug print the the scrutinee in the arm?
I'm surprised since we should return before calling for all other types. It must be one of the variants. That means we're using the of the associated const definition instead of the declaration. Maybe a defaulted associated const? I dunno.
Indeed, here's the source for the item being checked (specifically, ):
Ah okay. We should already be encoding the s for associated type defaults. If so, just adding an would resolve the issue. I think I can synthesize a test case from here though, so don't worry about reducing further. Thanks for the help!
No problem! Since I'd kicked this off already, here's the debug print:
Change:
}; let item = match item { <del> ast::ItemKind::Impl(u, o, a, b, c, items) => { let items = items.into_iter().filter_map(|item| self.configure(item)).collect(); ast::ItemKind::Impl(u, o, a, b, c, items) } ast::ItemKind::Trait(u, a, b, items) => { let items = items.into_iter().filter_map(|item| self.configure(item)).collect(); ast::ItemKind::Trait(u, a, b, items) } </del> ast::ItemKind::Struct(def, generics) => { ast::ItemKind::Struct(fold_struct(self, def), generics) }

Discussion:
no longer compiles on nightly due to what I think is a regression in macro hygiene: Here we have methods on a trait that are defined by hand, but implemented by macro. The function names are not generated by the macro - they're passed in, so I would not expect any hygiene shenanigans to apply. Possibly ? cc
Thanks for the report! I fixed this in -- it was caused by .
Change:
LL |     let x =  1.7976931348623159e+308_f64; |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: the literal `1.7976931348623159e+308_f64` does not fit into the type `f64` and will be converted to `std::f64::INFINITY` </del> <ins> = note: the literal `1.7976931348623159e+308_f64` does not fit into the type `f64` and will be converted to `f64::INFINITY` </ins> error: aborting due to 5 previous errors

Discussion:
This program: Produces this output: Note the references to ; these symbols have been superseded by associated consts at (). the error message to suggest the new symbols if any of the other old symbols are contained in any error messages. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also .
I am working on this. claim
: I've gone and grepped through for , , etc. and found no accidental uses there. I then grepped for each of the individual symbols listed in RFC 2700 (, , etc.) and didn't notice anything out of place. I also grepped for (as seen in this issue) and found only a hint message for things like etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once merges.
You are right. I was thinking of cases like this one but this can likely be closed with the merge of that PR. I was operating with an abundance of caution.
Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.
Change:
trace_mac: false, exported_macros: Vec::new(), syntax_env: env, <ins> recursion_count: 0, </ins> } }

Discussion:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows.

If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()
Change:
<ins> // Check what happens when `function` is used to define a function, instead of `fn` // edition:2021 #![allow(dead_code)] function foo() {} //~^ ERROR expected one of `!` or `::`, found `foo` //~^^ HELP write `fn` instead of `function` to declare a function fn main() {} </ins>

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Ideally the error message should suggest replacing or with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
New to rustc community and wants to contribute code. there any options to debug rustc which line of which file the error abort happens? can I dump the hierarchy tree for debugging use? C++ we usually use env for compiler debugging. How do rustc often use? Very newbie questions, thank you in advance.
label +E-easy +E-mentor Welcome to Rust! This might be some help -- This issue is very similar to , so take a peek at the diff there. IMO the following tokens are enough to check against function (Julia/JavaScript/etc) func (Go) fun (Kotlin) def (Python) Have fun! <3
Instructions -- Add a check if prevtoken is either ///etc Emit a message, something along the lines of "use instead of <prevtokento make a function" using , there are a few usages of this in the same file so those might be good examples. Add tests for this in -- Ideally each suggestion would have a test. Should be helpful to take as a reference
We can include if necessary.
Hi guys, another rust newbie looking for something easy to get started here. are you still on this or could go with my attempt here?

ypprog does seem to be active and it hasn't been that long, if you'd like you can pick another issue. =) Try going through the E-Easy and/or E-Mentor category for easy issues. However, to clarify, if an issue which is claimed doesn't seem to have any work done for a long period of time (A month or so is a good amount of time) -- Feel free to ping the assignee to confirm and handle it accordingly.
With these changes, I also think it is important to implement improved error messages for when a user puts the return type at the start of the function instead of the end. Given this code: The error output is:
I feel like adding might also be helpful for C++ developers :)
Is this still being worked on?
release-assignment
claim
Change:
|             ^^^------- |             | |             call expression requires function <ins> ... LL | fn foo(file: &str) -> bool { | -------------------------- this function of the same name is available here, but it's shadowed by the local binding </ins> error: aborting due to previous error

Discussion:
code: This causes a very confusing error message First, the message talks about "enum variant", does it mean ? Second, I don't get why it does not compile anyway. If I rename it builds, but why can't it figure out that that a var and function are different things even if they have the same name? Fun fact: this doesn't build either but this does: Shouldn't the 2 snippets behave identical?
They are not because on the second case the local binding doesn't exist yet, so the mod level function is not yet shadowed. In the other case, the function has been shadowed by the local binding, so it fails to compile. No, it's just confused thinking that is . The error message should mention the shadowing of the function.
Just ran into this again with a more simple case :( IMO this should compile because we know that is of type and not so querying the variable is the only thing that makes sense here..? The error message is not really helping imo I wonder if type ascription could solve this:
Change:
<ins> // Regression test for #80134. fn main() { (()é); //~^ ERROR: expected one of `)`, `,`, `.`, `?`, or an operator //~| ERROR: cannot find value `é` in this scope //~| ERROR: non-ascii idents are not fully supported (()氷); //~^ ERROR: expected one of `)`, `,`, `.`, `?`, or an operator //~| ERROR: cannot find value `氷` in this scope //~| ERROR: non-ascii idents are not fully supported } </ins>

Discussion:
Was reported here : but still occurring. <!-- 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
Simpler repro: ()
I assume this repros for any non-ascii character, right? I tried with ü, ß, and , and I was able to repro.
Correct :) é was just the character my big fingers typed when I found that bug!
Assigning and removing as .20.E2.80.A6) in the prioritization working group.
This is a regression since modify labels: +regression-from-stable-to-stable
Change:
= note: consult the function's documentation for information on how to avoid undefined behavior error: unnecessary `unsafe` block <del> --> $DIR/unsafe-env.rs:26:5 </del> <ins> --> $DIR/unsafe-env.rs:36:5 </ins> | LL |     unsafe { |     ^^^^^^ unnecessary `unsafe` block | note: the lint level is defined here <del> --> $DIR/unsafe-env.rs:11:8 </del> <ins> --> $DIR/unsafe-env.rs:21:8 </ins> | LL | #[deny(unused_unsafe)] |        ^^^^^^^^^^^^^ <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0133`.

Discussion:
<!-- 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 tried this code: I expected to see this happen: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- 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<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
Change:
<ins> // edition:2018 #![no_core] #![feature(no_core)] // @count macro.json "$.index[*][?(@.name=='macro')].inner.items[*]" 2 // @set repro_id = macro.json "$.index[*][?(@.name=='repro')].id" // @has - "$.index[*][?(@.name=='macro')].inner.items[*]" $repro_id #[macro_export] macro_rules! repro { () => {}; } // @set repro2_id = macro.json "$.index[*][?(@.inner.name=='repro2')].id" // @has - "$.index[*][?(@.name=='macro')].inner.items[*]" $repro2_id pub use crate::repro as repro2; </ins>

Discussion:
<brIn current stable, and nightly-2021-08-28: ! <brIn current beta, current nightly, and nightly-2021-08-29: ! <brNotice that appears twice in the sidebar under the list of macros exported by the crate. Bisects to .
searched nightlies: from nightly-2021-08-10 to nightly-2021-09-26 regressed nightly: nightly-2021-08-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It looks like in both versions there's also a bug where is not shown.
I think the fix here is to show "pub use repro as repro2" in the crate root - it sounds like currently it's being unconditionally inlined and then on top of that using the original name instead of the new one.
This also affect the unstable json output of rustdoc. If we take the example given by there are 3 items (1 reexport + 2 macro) instead of only two: The bug seems that the macro appears for whatever reason 2 times instead of only one.
Change:
<ins> // Regression test for #93205 #![crate_name = "foo"] mod generated { pub struct MyNewType; impl MyNewType { pub const FOO: Self = Self; } } pub use generated::MyNewType; mod prelude { impl super::MyNewType { /// An alias for [`Self::FOO`]. // @has 'foo/struct.MyNewType.html' '//a[@href="struct.MyNewType.html#associatedconstant.FOO"]' 'Self::FOO' pub const FOO2: Self = Self::FOO; } } </ins>

Discussion:
<!-- 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 tried this code: I expected to see this happen: intradoc links for the block residing in (where is not defined) are valid links. Instead, this happened: Rustdoc thinks that , resolved to , is not in scope here: A workaround is to make sure that , without prefix, is in scope: In other words, it seems that in intradoc links resolve to the name of the item, not the full path? <!-- 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. --:
I'll see if I can look into this. If someone else wants to work on it, feel free to claim it from me!
This appears to have since been fixed, probably by .
Actually, it'd probably be good to add a test for this.
Thanks! That looks to already have trickled down into recent stable rust releases, as I can't reproduce it with . Awesome!