jiebi/CodeConvo huggingface dataset:
Code change:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

Related discussion:
text: <ins> //@ check-pass #![allow(long_running_const_eval)] //@ compile-flags: -Z tiny-const-eval-limit -Z deduplicate-diagnostics=yes const FOO: () = { let mut i = 0; loop { //~^ WARN is taking a long time //~| WARN is taking a long time //~| WARN is taking a long time //~| WARN is taking a long time //~| WARN is taking a long time if i == 1000 { break; } else { i += 1; } } }; fn main() { FOO } </ins>
Code change:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

Related discussion:
text: <ins> warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: 5 warnings emitted </ins>
Code change:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

Related discussion:
text: } .item-info .stab { <del> /* This min-height is needed to unify the height of the stab elements because some of them have emojis. */ min-height: 36px; display: flex; </del> <ins> display: block; </ins> padding: 3px; margin-bottom: 5px; <del> align-items: center; vertical-align: text-bottom; </del> } .item-name .stab { margin-left: 0.3125em;
Code change:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

Related discussion:
text: color: var(--stab-code-color); } <del> .stab .emoji { </del> <ins> .stab .emoji, .item-info .stab::before { </ins> font-size: 1.25rem; <ins> } .stab .emoji { </ins> margin-right: 0.3rem; } <ins> .item-info .stab::before { /* ensure badges with emoji and without it have same height */ content: "0"; width: 0; display: inline-block; color: transparent; } </ins> /* Black one-pixel outline around emoji shapes */ .emoji { text-shadow: 1px 0 0 black, -1px 0 0 black, <del> 0  1px 0 black, </del> <ins> 0 1px 0 black, </ins> 0 -1px 0 black; }
Code change:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

Related discussion:
text: assert-size: (".item-info .stab", {"width": 289}) assert-position: (".item-info .stab", {"x": 245}) <ins> // We check that the display of the feature elements is not broken. It serves as regression // test for <https://github.com/rust-lang/rust/issues/118615>. set-window-size: (850, 800) store-position: ( "//*[@class='stab portability']//code[text()='Win32_System']", {"x": first_line_x, "y": first_line_y}, ) store-position: ( "//*[@class='stab portability']//code[text()='Win32_System_Diagnostics']", {"x": second_line_x, "y": second_line_y}, ) assert: |first_line_x| != |second_line_x| && |first_line_x| == 516 && |second_line_x| == 272 assert: |first_line_y| != |second_line_y| && |first_line_y| == 688 && |second_line_y| == 711 </ins> // Now we ensure that they're not rendered on the same line. <ins> set-window-size: (1100, 800) </ins> go-to: "file://" + |DOC_PATH| + "/lib2/trait.Trait.html" // We first ensure that there are two item info on the trait. assert-count: ("#main-content > .item-info .stab", 2)
Code change:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

Related discussion:
text: [lib] path = "lib.rs" <ins> [features] Win32 = ["Win32_System"] Win32_System = ["Win32_System_Diagnostics"] Win32_System_Diagnostics = ["Win32_System_Diagnostics_Debug"] Win32_System_Diagnostics_Debug = [] default = ["Win32"] </ins> [dependencies] implementors = { path = "./implementors" } http = { path = "./http" }
Code change:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

Related discussion:
text: // ignore-tidy-linelength #![feature(doc_cfg)] <ins> #![feature(doc_auto_cfg)] </ins> pub mod another_folder; pub mod another_mod;
Code change:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

Related discussion:
text: /// Some documentation /// # A Heading pub fn a_method(&self) {} <ins> #[cfg(all( feature = "Win32", feature = "Win32_System", feature = "Win32_System_Diagnostics", feature = "Win32_System_Diagnostics_Debug" ))] pub fn lot_of_features() {} </ins> } #[doc(cfg(feature = "foo-method"))]
Code change:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: compiles <!-- 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 in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: return; } }; <del> let (sig, map) = tcx.instantiate_bound_regions(sig, |br| { </del> <ins> let (unnormalized_sig, map) = tcx.instantiate_bound_regions(sig, |br| { </ins> use crate::renumber::RegionCtxt; let region_ctxt_fn = || {
Code change:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: compiles <!-- 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 in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: region_ctxt_fn, ) }); <del> debug!(?sig); </del> <ins> debug!(?unnormalized_sig); </ins> // IMPORTANT: We have to prove well formed for the function signature before // we normalize it, as otherwise types like `<&'a &'b () as Trait>::Assoc` // get normalized away, causing us to ignore the `'b: 'a` bound used by the function.
Code change:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: compiles <!-- 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 in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // // See #91068 for an example. self.prove_predicates( <del> sig.inputs_and_output.iter().map(|ty| { </del> <ins> unnormalized_sig.inputs_and_output.iter().map(|ty| { </ins> ty::Binder::dummy(ty::PredicateKind::Clause(ty::ClauseKind::WellFormed( ty.into(), )))
Code change:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: compiles <!-- 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 in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: term_location.to_locations(), ConstraintCategory::Boring, ); <del> let sig = self.normalize(sig, term_location); </del> <ins> let sig = self.normalize(unnormalized_sig, term_location); // HACK(#114936): `WF(sig)` does not imply `WF(normalized(sig))` // with built-in `Fn` implementations, since the impl may not be // well-formed itself. if sig != unnormalized_sig { self.prove_predicates( sig.inputs_and_output.iter().map(|ty| { ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::WellFormed(ty.into()), )) }), term_location.to_locations(), ConstraintCategory::Boring, ); } </ins> self.check_call_dest(body, term, &sig, *destination, *target, term_location); // The ordinary liveness rules will ensure that all