jiebi/CodeConvo huggingface dataset:
Change:
use rustc_hir as hir; use rustc_infer::infer::TyCtxtInferExt; <del> use rustc_macros::LintDiagnostic; use rustc_middle::ty::{self, fold::BottomUpFolder, Ty, TypeFoldable}; </del> <ins> use rustc_macros::{LintDiagnostic, Subdiagnostic}; use rustc_middle::ty::{ self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, Ty, TypeFoldable, }; </ins> use rustc_span::Span; use rustc_trait_selection::traits; use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt;

Discussion:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.
Change:
found type `()` error[E0308]: mismatched types <del> --> $DIR/async-block-control-flow-static-semantics.rs:60:50 </del> <ins> --> $DIR/async-block-control-flow-static-semantics.rs:59:50 </ins> | LL | fn rethrow_targets_async_block_not_async_fn() -> Result<u8, MyErr> { |    ----------------------------------------      ^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found ()

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.
Change:
<ins> warning: variant is never constructed: `B` --> $DIR/issue-87097.rs:6:5 | LL |     B, |     ^ | = note: `#[warn(dead_code)]` on by default warning: unused closure that must be used --> $DIR/issue-87097.rs:17:5 | LL | /     || match out_ref { LL | |         Variant::A => (), LL | |         Variant::B => (), LL | |     }; | |______^ | = note: `#[warn(unused_must_use)]` on by default = note: closures are lazy and do nothing unless called warning: unused closure that must be used --> $DIR/issue-87097.rs:26:5 | LL | /     || match here.field { LL | |         Variant::A => (), LL | |         Variant::B => (), LL | |     }; | |______^ | = note: closures are lazy and do nothing unless called warning: 3 warnings emitted </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. --Nightly only, since it depends on the feature gate. Without the feature gate, the code compiles without an ICE. is the first nightly with the ICE. Still occurs on the latest nightly ( at the time of writing). ICE still occurs when is substituted with , e.g. <!-- 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
cc
can you take a look please
I started looking into the issue and I think it spans from failing to resolve the upvars when the feature is enabled: fails which leads to the field of the Candidate to not be assigned as the assignment of this field is being done
The underlying issue is that currently the compiler does not realize, for the above example, that the discriminant should be read. We incorrectly assumed that would only be of type when they could be of other types like we should be looking at the when we actually want to look at Working on a fix
Change:
fn describe(tcx: TyCtxt, key: ty::ParamEnvAnd<'tcx, GlobalId<'tcx>>) -> String { format!("const-evaluating `{}`", tcx.item_path_str(key.value.instance.def.def_id())) } <ins> #[inline] fn cache_on_disk(_key: Self::Key) -> bool { true } #[inline] fn try_load_from_disk<'a>(tcx: TyCtxt<'a, 'tcx, 'tcx>, id: SerializedDepNodeIndex) -> Option<Self::Value> { tcx.on_disk_query_result_cache.try_load_query_result(tcx, id).map(Ok) } </ins> } impl<'tcx> QueryDescription<'tcx> for queries::mir_keys<'tcx> {

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
return wrap(ConstantExpr::getInBoundsGetElementPtr(unwrap(Ty), Val, IdxList)); } <ins> extern "C" bool LLVMRustConstIntGetZExtValue(LLVMValueRef CV, uint64_t *value) { auto C = unwrap<llvm::ConstantInt>(CV); if (C->getBitWidth() > 64) return false; *value = C->getZExtValue(); return true; } </ins> // Returns true if both high and low were successfully set. Fails in case constant wasn’t any of // the common sizes (1, 8, 16, 32, 64, 128 bits) extern "C" bool LLVMRustConstInt128Get(LLVMValueRef CV, bool sext, uint64_t *high, uint64_t *low)

Discussion:
Array created using repeat expression and returned from a function actually returns . Interestingly the problem does not happen when using the list syntax to create the array. I tried this code: I expected to see this happen: the second should pass Instead, this happened: the second fails screaming that Problem exists on stable, beta and nightly : <details<summaryBacktrace</summary<p</p</details
I wonder if is at fault here. It does look to be inappropriately turning the repeat into a memset (when looking at the llvm IR)
Compiling this: with Yields: Which does not seem right. We shouldn't be emitting a memset to 0 there.
This program hits an LLVM assertion if compiled with an LLVM that has assertions enabled:
This appeared in . Until the sample would code emit a compile error (), maybe that would shadow the error? A bisection between those two stable releases points to a group of old PR but I can't really pinpoint one :/
fails even under 1.26. And before that, i128 didn't even exist. So this has been a problem since 128 bit ints were introduced, as far as I can see.
Thank you for the analysis and the fix :)
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> error[E0428]: the name `Foo` is defined multiple times --> $DIR/issue-106072.rs:4:1 | LL | struct Foo; | ----------- previous definition of the type `Foo` here LL | trait Foo {} | ^^^^^^^^^ `Foo` redefined here | = note: `Foo` must be defined only once in the type namespace of this module error[E0782]: trait objects must include the `dyn` keyword --> $DIR/issue-106072.rs:1:10 | LL | #[derive(Clone)] |          ^^^^^ | = note: this error originates in the derive macro `Clone` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0782]: trait objects must include the `dyn` keyword --> $DIR/issue-106072.rs:1:10 | LL | #[derive(Clone)] |          ^^^^^ | = note: this error originates in the derive macro `Clone` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors Some errors have detailed explanations: E0428, E0782. For more information about an error, try `rustc --explain E0428`. </ins>

Discussion:
Given the following code: The current output is: Ideally the output should not suggest placing before in because the keyword is not valid in that position. Thank you to for finding the minimum reproducible that I used for this issue. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Regression test for // https://github.com/rust-lang/rust/issues/67945#issuecomment-572617285 // revisions: full min #![cfg_attr(full, feature(generic_const_exprs))] #![cfg_attr(full, allow(incomplete_features))] struct Bug<S> { //[min]~ ERROR: parameter `S` is never used A: [(); { //[full]~ ERROR: overly complex generic constant let x: Option<Box<S>> = None; //[min]~^ ERROR: generic parameters may not be used in const operations 0 }], } fn main() {} </ins>

Discussion:
The following ICE's on nightly and beta: <details<summaryBacktrace:</summary</details
Reduced: ICE most likely occurs in: I cannot seem to reproduce this without an , so cc
Reduced even more: (Please include all 3 variants thus far in a regression test.)
I looked into this briefly and found that on this line: has the value: Digging a bit deeper, the generics appear to be empty because of the following lines: I can confirm that adding makes this code compile, so I suspect that this is blocked on .
What would be the consequences of always returning the DefId?
It causes query cycle errors at the moment.
Discussed at T-compiler meeting. Due to all the known examples being compile-time errors, the ICE here does not seem so strong a hazard as to warrant weekly visits during triage. (Certainly failing more gracefully would be great. But its not something we're going to e.g. block a release on.) Downgrading priority to P-medium.
Some relevant examples. This gives an (incorrect) error on stable that does not hold: This ICEs on stable:
Is there a reason why we can't just disallow type parameters from appearing within constants during resolve, like we do for type parameters from outer functions? Obviously const generics/lazy normization willl loosen this rule.
good point, I imagine that might work.
Another variant on this bug:
Triage: The two examples that Centril posted ( and ) are no longer ICEs in the latest nightly. Possibly related to ?
Maybe we should just add tests then?
Sounds good! I'll do later.
Another variant (though likely the same): This gives a different to the original, despite being essentially the same code.
Triage: All the snippets including the original are no longer ICE with the latest nightly:
Change:
// see [1]. // // [1]: https://github.com/rust-lang/rust/pull/103172#discussion_r999139997 <ins> let param_env = tcx.param_env_reveal_all_normalized(def_id); </ins> let mut deduced_param_attrs = tcx.arena.alloc_from_iter( body.local_decls.iter().skip(1).take(body.arg_count).enumerate().map( |(arg_index, local_decl)| DeducedParamAttrs { read_only: !deduce_read_only.mutable_args.contains(arg_index) <del> && local_decl.ty.is_freeze(tcx, ParamEnv::reveal_all()), </del> <ins> && local_decl.ty.is_freeze(tcx, param_env), </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. -- (requires release mode) <!-- 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. --: 1.70.0-nightly (2023-04-02 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details labels modify +F-specialization +requires-nightly +requires-incomplete-features
I understand how this ICE can come about, but I frankly cannot reproduce this. can you help out?
Ah, I apparently forgot to list that the ICE requires ; building without optimizations doesn't ICE.
label +F-specialization +requires-nightly +requires-incomplete-features
Change:
|               `y` is a reference that is only valid in the closure body error[E0594]: cannot assign to `x`, as it is not declared as mutable <del> --> $DIR/issue-45983.rs:17:18 </del> <ins> --> $DIR/issue-45983.rs:36:18 </ins> | LL |     let x = None; |         - help: consider changing this to be mutable: `mut x`

Discussion:
D'oh: while investigating , I found a case where we are downgrading the NLL errors to warnings (due to the migration mode in ), but AST-borrowck issues an error for the test! (This may explain , at least in part...) Namely, . Here is the test: Here is the AST-borrowck output (a hard error): And here is the NLL output (another hard error): But here is the output from : ui/borrowck/issue- is one particular instance of this, but now that I've found one, I'm certain there are more. This is pretty bad. Very high priority to fix.
This code looks suspicious:
Ha I should have just left this to to fix, since we seem to have independently identified the culprit.
I think I've already assigned myself to enough issues.
Change:
<ins> //@ ignore-gdb //@ compile-flags:-g // === LLDB TESTS ================================================================================= // lldb-command:run // lldb-command:print pathbuf // lldb-check:[...] "/some/path" { inner = "/some/path" { inner = { inner = size=10 { [0] = '/' [1] = 's' [2] = 'o' [3] = 'm' [4] = 'e' [5] = '/' [6] = 'p' [7] = 'a' [8] = 't' [9] = 'h' } } } } // lldb-command:po pathbuf // lldb-check:"/some/path" // lldb-command:print path // lldb-check:[...] "/some/path" { data_ptr = [...] length = 10 } // lldb-command:po path // lldb-check:"/some/path" use std::path::Path; fn main() { let path = Path::new("/some/path"); let pathbuf = path.to_path_buf(); zzz(); // #break } fn zzz() { () } </ins>

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
}) .collect::<Vec<_>>(); let crate_def_id = CRATE_DEF_ID.to_def_id(); <ins> // Try to filter out intrinsics candidates, as long as we have // some other candidates to suggest. let intrinsic_candidates: Vec<_> = candidates .drain_filter(|sugg| { let path = path_names_to_string(&sugg.path); path.starts_with("core::intrinsics::") || path.starts_with("std::intrinsics::") }) .collect(); if candidates.is_empty() { // Put them back if we have no more candidates to suggest... candidates.extend(intrinsic_candidates); } </ins> if candidates.is_empty() && is_expected(Res::Def(DefKind::Enum, crate_def_id)) { let mut enum_candidates: Vec<_> = self .r

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: The current output is: Ideally the output should look like: In cases where intrinsics have been stabilised in | it would be useful to suggest these to users first. Especially as using intrinsics generates another error that tells you to prefer stabilized functions in . This would hopefully make handling this error easier for new rust users coming from languages like C/C++ and looking for the equivalent of <!-- 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. --The output is the same on stable, beta and nightly
I'd be satisfied if we filtered out intrinsics altogether except for when the feature was enabled.
I also get quite annoyed when stable rustc recommends I use unstable features (maybe that should be fixed in an RFC)
Checking the DefId of each suggested path to see if they are annotated with should be doable.
This seems to be harder than I initially thought... so since we emit this "consider importing" suggestion in , we do not have access to it seems. And I have no idea how to extract the attributes from each without ... :thinking:
We might want to consider adding yet another dumping ground field in the itself or in ... But at that point it seems like too much mem consumption for little gain. The other option is to delay the emitting of these errors until later, but that also seems... like a lot of additional complexity :-/
For now, I guess it wouldn't hurt just to filter suggesting paths that are literally (and ) instead of going thru all of the work of adding more info to the . I can put up a PR that does that later.
Change:
<ins> // check-pass #![crate_type = "lib"] #[cfg(target_arch = "wasm32")] mod wasm_non_clash { mod a { #[link(wasm_import_module = "a")] extern "C" { pub fn foo(); } } mod b { #[link(wasm_import_module = "b")] extern "C" { pub fn foo() -> usize; // #79581: These declarations shouldn't clash because foreign fn names are mangled // on wasm32. } } } </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. --Rustc 1.48.0 gives an incorrect warning about an external symbol being redeclared with a different signature, when the external symbols are in different namespaces. I tried this code: I expected to see this happen: Compile without warnings 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. --: The same behavior exists on nightly as well: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
cc would you be willing to help take a look at this? (it looks like you this way-back-when in ) On wasm targets there's which is why this should work but not actually generate a warning. Do you know if it's possible to call that logic perhaps? (would be able to consolidate "what's the name of this symbol" logic too!)
Sure thing! I'm currently in the process of moving, but will be able to get onto this on the weekend :) claim
No worries, and thanks! If you run out of time/steam I'm happy to look into this as well
Change:
} #[test] <ins> fn lonely_sign() { assert!("+".parse::<f32>().is_err()); assert!("-".parse::<f64>().is_err()); } #[test] fn whitespace() { assert!(" 1.0".parse::<f32>().is_err()); assert!("1.0 ".parse::<f64>().is_err()); } #[test] </ins> fn nan() { assert!("NaN".parse::<f32>().unwrap().is_nan()); assert!("NaN".parse::<f64>().unwrap().is_nan());

Discussion:
I tried this code: I expected to see this happen: "Error: invalid float literal" Instead, this happened: OK: 0 It seems the "leading +" and "leading -" is broken. Further, with i32 and i64 is emits an error but IMO an incorrect one: "cannot parse integer from empty string" I would expect: "Invalid integer literal" : rustc 1.5.0-nightly ( 2015-10-11) binary: rustc commit-hash: commit-date: 2015-10-11 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Oh my, the float part is embarrassing. Preparing a fix right now.
Thanks for taking a look Looks like this is working as expected on stable and has leaked into beta/nightly, so tagging as such.
Yes, this is a bug (not checking for empty strings in the right places) of the dec2flt code. The bug is also in beta, so the PR (which I'll file very soon) should probably be backported to beta.
Change:
use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexSet}; use rustc_errors::{struct_span_err, Applicability}; use rustc_hir as hir; <del> use rustc_hir::def::{CtorKind, DefKind, Res}; </del> <ins> use rustc_hir::def::{CtorKind, DefKind}; </ins> use rustc_hir::def_id::{DefId, LocalDefId, LOCAL_CRATE}; use rustc_hir::intravisit::{self, NestedVisitorMap, Visitor}; use rustc_hir::weak_lang_items;

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --