jiebi/CodeConvo huggingface dataset:
Change:
trait_def.generics.types.as_slice(), trait_def.generics.regions.as_slice(), trait_ref.substs, <del> self.invariant); </del> <ins> variance); </ins> } ty::ty_trait(ref data) => {

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',
Change:
potential_assoc_types) }; <del> if !infer_lifetimes || arg_counts.lifetimes > param_counts.lifetimes { </del> <ins> if reported_late_bound_region_err.is_none() && (!infer_lifetimes || arg_counts.lifetimes > param_counts.lifetimes) { </ins> check_kind_count( "lifetime", param_counts.lifetimes,

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
} } <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> impl<'a, I, T: 'a> FusedIterator for Copied<I> where I: FusedIterator<Item=&'a T>, T: Copy {}

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
unsafe { errno as i32 } } <ins> #[cfg(target_os = "dragonfly")] pub fn set_errno(e: i32) { extern { #[thread_local] static mut errno: c_int; } unsafe { errno = e; } } </ins> /// Gets a detailed string description for the given error number. pub fn error_string(errno: i32) -> String { extern {

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.
Change:
/// only a single type (e.g., `(u32, u32)`). Such aggregates are often /// special-cased in ABIs. /// <del> /// Note: We generally ignore fields of zero-sized type when computing /// this value (see #56877). </del> <ins> /// Note: We generally ignore 1-ZST fields when computing this value (see #56877). </ins> /// /// This is public so that it can be used in unit tests, but /// should generally only be relevant to the ABI details of

Discussion:
On aarch64-unknown-linux-gnu (a tier 1 target), consider this testcase: passes its argument as uses IOW, uses float registers and uses int registers. This violates our promise that types are ABI-compatible. I think this might indicate a bug in the function? At least I don't see anything in the aarch64 adjustment that would be obviously wrong.
This also affects arm32 targets like arm-unknown-linux-gnueabihf.
Yes, that is definitely the issue -- that is heterogeneous.
Should be fixed by
Change:
Terminator { kind: TerminatorKind::Goto { ref mut target }, .. } => target, _ => unreachable!(), }; <ins> *changed |= *target != last; </ins> *target = last; debug!("collapsing goto chain from {:?} to {:?}", current, target);

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. --repo @ Rustc simply hangs when running Edit: while rustc is crunching on the hang:
cc ? edit: I assume this is due to
O_o yea, I'll have a look
Wild speculation: might have the same cause (EDIT: Backtrace says yes)
Change:
if let (Some((expr, _)), Some((fn_decl, _, _))) = (expression, fcx.get_node_fn_decl(parent_item)) { <del> fcx.suggest_missing_return_expr(&mut err, expr, fn_decl, expected, found, parent_id); </del> <ins> fcx.suggest_missing_break_or_return_expr( &mut err, expr, fn_decl, expected, found, id, parent_id, ); </ins> } if let (Some(sp), Some(fn_output)) = (fcx.ret_coercion_span.get(), fn_output) {

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: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- 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 --
label +A-suggestion-diagnostics
claim
Change:
} self.cx.tcx.for_each_relevant_impl(trait_def_id, ty, |impl_def_id| { self.cx.tcx.infer_ctxt().enter(|infcx| { <ins> debug!("get_blanet_impls: Considering impl for trait '{:?}' {:?}", trait_def_id, impl_def_id); </ins> let t_generics = infcx.tcx.generics_of(impl_def_id); let trait_ref = infcx.tcx.impl_trait_ref(impl_def_id) .expect("Cannot get impl trait");

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
<ins> // Regression test for #58490 macro_rules! a { ( @1 $i:item ) => { a! { @2 $i } }; ( @2 $i:item ) => { $i }; } mod b { a! { @1 #[macro_export] macro_rules! b { () => () } } #[macro_export] macro_rules! b { () => () } //~^ ERROR: the name `b` is defined multiple times } mod c { #[allow(unused_imports)] use crate::b; } fn main() {} </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> // Regression test for #58490 macro_rules! a { ( @1 $i:item ) => { a! { @2 $i } }; ( @2 $i:item ) => { $i }; } mod b { a! { @1 #[macro_export] macro_rules! b { () => () } } #[macro_export] macro_rules! b { () => () } //~^ ERROR: the name `b` is defined multiple times } mod c { #[allow(unused_imports)] use crate::b; } fn main() {} </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
_ => None, }) .expect("Expected associated type binding"); <ins> debug!("Render deref methods for {:#?}, target {:#?}", impl_.inner_impl().for_, target); </ins> let what = AssocItemRender::DerefFor { trait_: deref_type, type_: real_target, deref_mut_: deref_mut }; if let Some(did) = target.def_id_full(cx.cache()) {

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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.
Change:
} #[stable(feature = "rust1", since = "1.0.0")] <del> impl<T> fmt::Display for TryLockError<T> { </del> <ins> impl<T: Send> fmt::Display for TryLockError<T> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { self.description().fmt(f) } } <del> impl<T> Error for TryLockError<T> { </del> <ins> impl<T: Send> Error for TryLockError<T> { </ins> fn description(&self) -> &str { match *self { TryLockError::Poisoned(ref p) => p.description(),

Discussion:
currently requires , while requires . I'm unsure of what each should require, but I think they should agree so that it is possible to have code which returns (which is useful to allow try! across functions returning different types of error codes), and be able to the results.
There was a lengthy discussion about this towards the bottom of the RFC:
/cc , I vaguely remember this might change? If not, then this should be in the RFCs repo.
Nominating for 1.0-beta P-backcompat-libs. (The trait isn't yet, but it probably will be for 1.0).
0 beta, P-backcompat-libs, I-needs-decision.
Change:
if val < 0 { neg = true; } <del> Some(val.wrapping_abs() as u128) </del> <ins> Some(val.unsigned_abs()) </ins> }) } _ => {

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
help: consider using the `'_` lifetime | LL |     fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result { <del> |                             ~~~~~~~~~~~~~~~~~~ </del> <ins> |                                  ~~~~~~~~~~~~~ </ins> warning: variable `Social_exchange_psychology` should have a snake case name --> $DIR/reasons.rs:30:9

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 (which works correctly with rustc 1.57.0 stable): But with , I get: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also consider the following code, which creates an error message that could be more precise. I wouldn't call the following example a bug, but maybe these two issues are related: () Error output:
I think this is due to cc: let me see if I can fix this real quick.
claim
label +regression-from-stable-to-nightly +A-diagnostics
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<ins> warning: the feature `adt_const_params` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-97047-ice-1.rs:3:12 | LL | #![feature(adt_const_params, generic_const_exprs)] |            ^^^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #95174 <https://github.com/rust-lang/rust/issues/95174> for more information warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-97047-ice-1.rs:3:30 | LL | #![feature(adt_const_params, generic_const_exprs)] |                              ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information warning: 2 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. --<!-- 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
A reduced version: Tested in using
The other ICE block is also standalone
for the first example: ` Regression in :thinking: EDIT: same for the second snippet.
This is caused by Seems as if this issue takes care of FIXME ^^. Not sure what the right solution is, we originally tried to skip reborrows because implicit autorefs/autoderefs lead to confusing error messages given that we don't support derefs and refs in abstract consts. Maybe the right solution is to just clarify that autorefs/autoderefs happen there. Thoughts
No longer ICEs since (perhaps due to ?)