jiebi/CodeConvo huggingface dataset:
Change:
| sym::u32 | sym::i64 | sym::u64 <ins> | sym::i128 | sym::u128 </ins> | sym::isize | sym::usize => { int_reprs += 1;

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: compilation failure Instead, this happened: Compiles, outputs "0" <!-- 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. --: Also: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Should be a easy fix. claim
Change:
|| self.tcx.is_builtin_derive(def_id) }) .filter_map(|def_id| self.tcx.impl_trait_ref(def_id)) <del> // Avoid mentioning type parameters. .filter(|trait_ref| !matches!(trait_ref.self_ty().kind(), ty::Param(_))) </del> <ins> .filter(|trait_ref| { let self_ty = trait_ref.self_ty(); // Avoid mentioning type parameters. if let ty::Param(_) = self_ty.kind() { false } // Avoid mentioning types that are private to another crate else if let ty::Adt(def, _) = self_ty.peel_refs().kind() { // FIXME(compiler-errors): This could be generalized, both to // be more granular, and probably look past other `#[fundamental]` // types, too. self.tcx .visibility(def.did()) .is_accessible_from(body_id.owner.to_def_id(), self.tcx) } else { true } }) </ins> .collect(); return report(normalized_impl_candidates, err); }

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. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
use std::sync::atomics; use std::vec; use syntax::codemap::{Span, Pos}; <del> use syntax::{ast, codemap, ast_util, ast_map, opt_vec}; </del> <ins> use syntax::{abi, ast, codemap, ast_util, ast_map, opt_vec}; </ins> use syntax::parse::token; use syntax::parse::token::special_idents;

Discussion:
Here's a recent session of mine Even if I continue into my own function (actually the symbol ), I'm not getting any source level debugging. Is there an extra option that I should be passing or should this be "just working"? I compiled a C executable with and I got nice debug-info without doing anything extra in lldb. cc
This is a known issue with the Servo team, fwiw.
Does clang give you usable debug symbols?
I do indeed get nice debugging with clang:
Could you dump the IR from clang and rustc for similar programs?
I'd also be interested in seeing if clang produces dSYM bundles and whether there are any observable differences between them and the ones that rustc produces. Relevant literature at .
This has the two IR outputs:
Clang: rustc: That's some strong difference there.
I spent a while tracking this down due to a red herring, but the actual issue is simple: the DWARF version is too high. As of OS X 10.9, 'dwarfdump' and 'dsymutil', the latter of which is required to aggregate DWARF info from .o files into the final executable, appear to ignore DWARF information with version 3. Rust uses LLVM's default of DWARF 4. clang defaults to DWARF 2 on OS X; in fact, the version of clang distributed with Xcode (but not the version I have installed through MacPorts? too tired to investigate this properly) seems to ignore -gdwarf-3 and above, so probably better to go with 2 than 3. Workaround: . I believe the correct way to solve this is for rustc to set the LLVM module flag "Dwarf Version", as clang does. It should also set "Debug Info Version", which, as far as I can tell, causes a separate issue where anything reading bitcode files using a new version of LLVM (e.g. the versions of llvm-dis or llc compiled by rust) will magically discard all the debug metadata.
you are my new favorite person in the world, thank you for figuring this out!!! I would be more than ok accepting a patch to pass these arguments by default! Pull requests are always welcome :)
Ship it, shipt it! :cactus:
This is a great find indeed!

For anyone interested, here is another source of information on DWARF on Mac OS X: The DWARF standard says that namespaces are not supported yet in version 2. I'd be interested in what the consequences of this are. Other than that I don't think we use anything that needs a newer version than 2. I'd be happy to turn this information into a fix and a pull request but I don't have a Mac to test it (yet). Thanks again :+1:
cc me
Change:
<ins> // aux-build:issue-117997.rs // build-pass extern crate issue_117997; pub fn main() { issue_117997::get_assoc().method_on_assoc(); } </ins>

Discussion:
This is a pretty common use case, so this bug has probably already been registered, but I couldn't find anything while searching around, so I'm reporting this here just in case. I ran this code: When running this code, I expect to simply get a not yet implemented error on the function. Instead, I get this: : returns an , and is not a trait method–it's just a regular method. Therefore, AFAIK, this should compile. Notably, making either or as makes it compile fine.
Regression in . cc
oli's on leave so cc-ing PR 's reviewer
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
); } (_, false, _) => { <ins> debug!( "note_type_err: exp_found={:?}, expected={:?} found={:?}", exp_found, expected, found ); </ins> if let Some(exp_found) = exp_found { self.suggest_as_ref_where_appropriate(span, &exp_found, diag); }

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.
Change:
<del> Subproject commit 942aa2b5d729a63f8b81592ab7b2720b63a884e9 </del> <ins> Subproject commit 48ef96dd00b90d950a122ca180923aba77efaf74 </ins>

Discussion:
recently started saying something like this several times on almost every invocation:
Probably caused by Cc
is there any way for us to make that warning an error? Ideally this wouldn't pass CI...
It was done to fix CI in RLS repo and has no effect on Rust. Why should it be a hard error?
It's worth noting that functionally it doesn't change anything - the section in the RLS manifest should always point to the version checked in the submodule. I'll update the RLS. I understood that this use case might be useful to support in some way - my intent was to patch the dependency from the crate PoV to emphasize that pulling Rustfmt from git is a temporary measure and a regular dependency should be used eventually there, rather than trying to globally patch the rustfmt (which is already done by the final Rust virtual manifest).
It should be a hard error or silenceable -- we shouldn't have warnings on master.
AFAIK it's hardcoded. I've suggested introduction of lints in , to build upon . The largest implementation complexity I see with the cargo feature is in fact non-cargo lints because rustc prints the source of the lint level, and if cargo sets arguments, rustc would only see those and thus complain about arguments to the users. Maybe initially the feature could only allow lints, with rustc lints coming once it's figured out how to get rustc print the source of the lint level. It would be great to have this feature for as well so that one doesn't need to support in random compilation units.
Yeah it's hardcoded to warn:
any news on updating RLS? I can take care of removing the patch and bumping the submodule to a separate branch on rust-lang/rls if you'd like (the patch shouldn't be needed for rust-lang/rust, but I guess is needed upstream).
You don't need a separate branch. You only have to create a different file and then change ci to do sth like .
I guess that would work too, but personally that seems somewhat more complicated and more likely to lead to problems of only updating one of them.
Change:
} let projection_ty = if let ty::AssocKind::Fn = assoc_kind { <del> let mut emitted_bad_param_err = false; </del> <ins> let mut emitted_bad_param_err = None; </ins> // If we have an method return type bound, then we need to substitute // the method's early bound params with suitable late-bound params. let mut num_bound_vars = candidate.bound_vars().len();

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeopnormalizeclause] normalizing [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Change:
<ins> // issue: 114146 #![feature(return_position_impl_trait_in_trait)] trait Foo { fn bar<'other: 'a>() -> impl Sized + 'a {} //~^ ERROR use of undeclared lifetime name `'a` //~| ERROR use of undeclared lifetime name `'a` } 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
This needs detailed investigation, and I'd prefer we fully understand why this is resulting in a region error over just adding an check to (or feeding the query).... This probably has to do with the fact that we have a due to the missing region .
Change:
(true, true) => "RelWithDebInfo", }; <ins> // NOTE: remember to also update `config.toml.example` when changing the defaults! let llvm_targets = match build.config.llvm_targets { Some(ref s) => s, None => "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc", }; </ins> cfg.target(target) .host(&build.config.build) .out_dir(&dst) .profile(profile) .define("LLVM_ENABLE_ASSERTIONS", assertions) <del> .define("LLVM_TARGETS_TO_BUILD", "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc") </del> <ins> .define("LLVM_TARGETS_TO_BUILD", llvm_targets) </ins> .define("LLVM_INCLUDE_EXAMPLES", "OFF") .define("LLVM_INCLUDE_TESTS", "OFF") .define("LLVM_INCLUDE_DOCS", "OFF")

Discussion:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.
Change:
let mut nested_result = EvaluationResult::EvaluatedToOk; for obligation in nested_obligations { nested_result = cmp::max( <del> this.evaluate_predicate_recursively(stack.list(), obligation)?, </del> <ins> this.evaluate_predicate_recursively(previous_stack, obligation)?, </ins> nested_result, ); }

Discussion:
I tried this code: I expected to see this happen: build failed, because this future doesn't implement Send, so this function shouldn't implement Instead, this happened: build pass <!-- 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<p</p</detailscargo-bisect-rustc show the Regression in this bug is introduced by this PR <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +T-types
I think it's a very serious bug, should we revert this change?
claim
minimized ah, figured out the issue how did you catch this bug?
I try to find the minimized example of there is a ICE with a unsend future in this issue
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Isn't this a stable-to-beta regression since nightly just branched?
Just to clarify since we're in the confusing week where stable & beta are discontinuous version numbers:
Change:
($ty:ident) => { #[stable(feature = "rust1", since = "1.0.0")] impl Debug for $ty { <ins> #[inline] </ins> fn fmt(&self, _fmt: &mut Formatter<'_>) -> Result { panic!("floating point support is turned off"); }

Discussion:
From ICEs at no symbol mangling. is required for the repro. The symbol mangling ICE was fixed in which is nominated for beta backport, but this seems to hint that something isn't marked that should be. I suspect that adding the above would probably break cggcc and cg_clif. From Miguel, this uses the most recent beta
label +F-f16andf128 +T-libs -needs-triage
The fallback impls for and are lacking an hint .
I did see that, just didn’t get a chance to test a fix for it yet. Care to put a patch up? (If not, I'll get to it at some point)
PR at .
Change:
<ins> // `Self` as a constructor is currently allowed when the outer item is not generic. // check-pass struct S0(usize); impl S0 { fn foo() { const C: S0 = Self(0); fn bar() -> S0 { Self(0) } } } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I made a blank cargo project (ran in an empty directory), and dependencies to my like so: Originally when I went to run , I was in nightly, and got a compile error (full error below). Then, when i switched to stable, there was no error and everything built fine! <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.69 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
searched nightlies: from nightly-2023-02-15 to nightly-2023-05-13 regressed nightly: nightly-2023-05-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsrollup it didn't want to bisect the perf builds for some reason but i guess or could be at fault? haven't looked into the actual issue in detail, since it's behind a macro you probably know something about this anyways even if it may not be your fault
its not that is genericconstexprs only code
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
<ins> error[E0594]: cannot assign to `*v` which is behind a `&` reference --> $DIR/issue-83309-ice-immut-in-for-loop.rs:11:9 | LL |     for v in Query.iter_mut() { |              ---------------- this iterator yields `&` references LL | LL |         *v -= 1; |         ^^^^^^^ `v` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>

Discussion:
Code that generated this error is available here: I am happy to spend some time trying to create a smaller repro but it will take me a few days. This error is reproducible on my machine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FYI, with this code compiled.
Minimized: Similar error was reported in . The issue is in code that attempts to suggest a different method, that might potentially return items. In that particular case there are no other suggestions to make, but code will attempt to emit diagnostic anyway, eventually failing the assertion: label: +E-easy
claim
label +regression-from-stable-to-beta
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
<ins> error[E0369]: cannot multiply `&mut Foo` by `&Foo` --> $DIR/borrow-suggestion-109352.rs:21:25 | LL |     let _ = ref_mut_foo * ref_foo; |             ----------- ^ ------- &Foo |             | |             &mut Foo | = note: an implementation for `&Foo * &Foo` exists help: consider reborrowing this side | LL |     let _ = &*ref_mut_foo * ref_foo; |             ++ error[E0369]: cannot multiply `&mut Foo` by `&mut Foo` --> $DIR/borrow-suggestion-109352.rs:23:25 | LL |     let _ = ref_mut_foo * ref_mut_foo; |             ----------- ^ ----------- &mut Foo |             | |             &mut Foo | = note: an implementation for `&Foo * &Foo` exists help: consider reborrowing both sides | LL |     let _ = &*ref_mut_foo * &*ref_mut_foo; |             ++              ++ error[E0369]: cannot multiply `&mut Foo` by `&Foo` --> $DIR/borrow-suggestion-109352.rs:25:25 | LL |     let _ = ref_mut_foo * &owned_foo; |             ----------- ^ ---------- &Foo |             | |             &mut Foo | = note: an implementation for `&Foo * &Foo` exists help: consider reborrowing this side | LL |     let _ = &*ref_mut_foo * &owned_foo; |             ++ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0369`. </ins>

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!