jiebi/CodeConvo huggingface dataset:
Change:
pub scope_span: Option<Span>, } <ins> BraceStructTypeFoldableImpl! { impl<'tcx> TypeFoldable<'tcx> for GeneratorInteriorTypeCause<'tcx> { ty, span, scope_span } } </ins> #[derive(RustcEncodable, RustcDecodable, Debug)] pub struct TypeckTables<'tcx> { /// The HirId::owner all ItemLocalIds in this table are relative to.

Discussion:
Hyper fails to compile on Rust master () <details</details
fyi
I also get this with on futures-rs <details</details
getting this while trying to compile rust itself(): <details</details
Confirming bisection range is
guessing it's PR attempting rust compilation with reverted like so: <details</detailsthis might take a while...
It's not it, surprisingly enough(for me). (manually)Reverting that PR fails the same. (that is, applied this on top of rust commit ) <details</details<details</details
? This PR adds to typeck-table which is stable-hashed, and the hyper ICE is happening on by querying that table, which looks relevant.
I've reversed-applied the patch from (aka reverted PR ) on top of rust like this , and the results are(74mins later, at least): it passed!(failed later, on clippy_lints, but that's unrelated) So that's the problematic PR, thanks Since rust got updated compared to my previous try, I'll re-apply this PR on top of what already worked just now to see if it indeed fails with it! <sWill post new comment with the update.</sConfirmed the ICE is back with that PR, using 's test-case: <details</details
Minimized test-case:
Thanks self-assigning to look into this (since I caused it with ) - if anyone else wants to look into fixing also, please feel free.
I have a WIP fix:
Change:
) { let cause = traits::ObligationCause::new(span, self.body_id, ObligationCauseCode::WellFormed(loc)); <ins> // for a type to be WF, we do not need to check if const trait predicates satisfy. let param_env = self.param_env.without_const(); </ins> self.ocx.register_obligation(traits::Obligation::new( cause, <del> self.param_env, </del> <ins> param_env, </ins> ty::Binder::dummy(ty::PredicateKind::WellFormed(arg)).to_predicate(self.tcx()), )); }

Discussion:
Found in : https://crater- Looking briefly into the code it's doing something pretty weird (e.g., transmutes ), but at the very least this diagnostic seems unfortunate.
searched nightlies: from nightly-2022-04-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis regressed in cc
Maybe "regressed" is better here, maybe it's a legitimate reason to fail. Haven't looked into it.
I'm going to look into this later, but it seems like a case of wf checks requiring const bounds.
Repro:
Just to be sure I understood: is the regression about code that should compile in the next Rust 1.64 or is that code now invalid code and the regression is just a bad diagnostic? thanks!
The code is valid. It should compile in the next Rust 1.64. Hope that helps.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> <h4 class="code-header">fn <a href="#method.touch" class="fnname">touch</a>(&amp;self)</h4> </ins>  No newline at end of file

Discussion:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim
Change:
<ins> warning: the feature `return_type_notation` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-120208-higher-ranked-const.rs:3:12 | LL | #![feature(return_type_notation)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #109417 <https://github.com/rust-lang/rust/issues/109417> for more information = note: `#[warn(incomplete_features)]` on by default error: return type notation is not allowed for functions that have const parameters --> $DIR/issue-120208-higher-ranked-const.rs:12:21 | LL |     async fn check<const N: usize>() -> bool; |                    -------------- const parameter declared here ... LL |     HC: HealthCheck<check(): Send> + Send + 'static, |                     ^^^^^^^^^^^^^ error: aborting due to 1 previous error; 1 warning emitted </ins>

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> error[E0437]: type `M` is not a member of trait `TraitB` --> $DIR/issue-69602-type-err-during-codegen-ice.rs:17:5 | LL |     type M   = A; |     ^^^^^^^^^^^^^ not a member of trait `TraitB` error[E0046]: not all trait items implemented, missing: `MyA` --> $DIR/issue-69602-type-err-during-codegen-ice.rs:16:1 | LL |     type MyA: TraitA; |     ----------------- `MyA` from trait ... LL | impl TraitB for B { | ^^^^^^^^^^^^^^^^^ missing `MyA` in implementation error: aborting due to 2 previous errors Some errors have detailed explanations: E0046, E0437. For more information about an error, try `rustc --explain E0046`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
/// # Examples /// /// ```rust <del> /// #![feature(slice_ptr_get, nonnull_slice_from_raw_parts)] </del> <ins> /// #![feature(slice_ptr_get)] </ins> /// use std::ptr::NonNull; /// /// let slice: NonNull<[i8]> = NonNull::slice_from_raw_parts(NonNull::dangling(), 3);

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
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] [ ] 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.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
: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. This will be merged soon.
Change:
# $(4) tag define DEF_PREPARE_TARGET_N # Rebind PREPARE_*_LIB_DIR to point to rustlib, then install the libs for the targets <del> prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_WORKING_SOURCE_LIB_DIR=$$(PREPARE_SOURCE_LIB_DIR)/rustlib/$(2)/lib prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(2)/lib prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_SOURCE_BIN_DIR=$$(PREPARE_SOURCE_LIB_DIR)/rustlib/$(3)/bin prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_DEST_BIN_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(3)/bin </del> <ins> prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_WORKING_SOURCE_LIB_DIR=$$(TLIB$(1)_T_$(2)_H_$(3)) prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(2)/lib prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_SOURCE_BIN_DIR=$$(TBIN$(1)_T_$(2)_H_$(3)) prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_DEST_BIN_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(3)/bin </ins> prepare-target-$(2)-host-$(3)-$(1)-$(4): prepare-maybe-clean-$(4)  $$(foreach crate,$$(TARGET_CRATES),  $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$$(crate)) 

Discussion:
There are no Windows nightlies currently being published: They appear to have been broken since at least Nov. 1. This prevents Servo from updating Rust. CC:
was looking into this earlier.
Change:
<ins> error[E0425]: cannot find function `unknown` in this scope --> $DIR/check-args-on-fn-err.rs:2:5 | LL |     unknown(1, |glyf| { |     ^^^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (
Change:
// 2       --------   // 2 ------- let (lo, hi) = self.boundaries(); let (other_lo, other_hi) = other.boundaries(); <del> (lo == other_hi || hi == other_lo) </del> <ins> lo == other_hi || hi == other_lo </ins> } fn to_pat(&self, tcx: TyCtxt<'tcx>) -> Pat<'tcx> {

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
error("can't find package with uuid: " + target); } else { <del> for os::list_dir(c.libdir).each { |file| </del> <ins> for os::list_dir(lib).each { |file| </ins> alt str::find_str(file, "lib" + target + "-") { some(idx) { <del> let full = path::normalize(path::connect(c.libdir, file)); </del> <ins> let full = path::normalize(path::connect(lib, file)); if os::remove_file(full) { info("uninstalled: '" + full + "'"); } else { error("could not uninstall: '" + full + "'"); } ret; } none { cont; } } } for os::list_dir(bin).each { |file| alt str::find_str(file, target) { some(idx) { let full = path::normalize(path::connect(bin, file)); </ins> if os::remove_file(full) { info("uninstalled: '" + full + "'"); } else {

Discussion:
We should be publishing a "default" local- file on rust- (or, at minimum, our github repo for now). When you run cargo for the first time it should fetch this if it hasn't got a local- file, and there should be a "cargo init" command or something that re-fetches this default.
handles this.
Looks like it doesn't auto-fetch yet.
Change:
41. “ControlFlowIntegrity.” The Rust Unstable Book. [https://doc.rust-lang.org/unstable-book/compiler-flags/sanitizer.html#controlflowintegrity](../unstable-book/compiler-flags/sanitizer.html#controlflowintegrity). <ins> 42. bbjornse. “add codegen option for using LLVM stack smash protection #84197.” GitHub. <https://github.com/rust-lang/rust/pull/84197> </ins>

Discussion:
Stack smashing protection was in , but  was never updated. label A-docs
Have you started on this already? I'm available to take this on. I came across the docs before the PR, and was misled about the current state of this feature.
Not yet. Sorry about the confusion caused by it. If you'd have time to and would like to contribute, it'd be much appreciated. Feel free to CC me in the PR and I'd be happy to help reviewing it.
Change:
rustc_fluent_macro::fluent_messages! { "../messages.ftl" } fn require_c_abi_if_c_variadic(tcx: TyCtxt<'_>, decl: &hir::FnDecl<'_>, abi: Abi, span: Span) { <del> const CONVENTIONS_UNSTABLE: &str = "`C`, `cdecl`, `aapcs`, `win64`, `sysv64` or `efiapi`"; </del> <ins> const CONVENTIONS_UNSTABLE: &str = "`C`, `cdecl`, `system`, `aapcs`, `win64`, `sysv64` or `efiapi`"; </ins> const CONVENTIONS_STABLE: &str = "`C` or `cdecl`"; const UNSTABLE_EXPLAIN: &str = "using calling conventions other than `C` or `cdecl` for varargs functions is unstable";

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
} } <ins> // Unify the whole function signature. We need to do this to fully infer // the lifetimes of the return type, but do this after unifying just the // return types, since we want to avoid duplicating errors from // `compare_predicate_entailment`. match infcx .at(&cause, param_env) .eq(tcx.mk_fn_ptr(ty::Binder::dummy(trait_sig)), tcx.mk_fn_ptr(ty::Binder::dummy(impl_sig))) { Ok(infer::InferOk { value: (), obligations }) => { ocx.register_obligations(obligations); } Err(terr) => { let guar = tcx.sess.delay_span_bug( return_span, format!("could not unify `{trait_sig}` and `{impl_sig}`: {terr:?}"), ); return Err(guar); } } </ins> // Check that all obligations are satisfied by the implementation's // RPITs. let errors = ocx.select_all_or_error();

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim
Change:
} else { 4 }; <ins> let normalize = |candidate| self.tcx.global_tcx().infer_ctxt().enter(|ref infcx| { let normalized = infcx .at(&ObligationCause::dummy(), ty::ParamEnv::empty()) .normalize(candidate) .ok(); match normalized { Some(normalized) => format!("n  {:?}", normalized.value), None => format!("n  {:?}", candidate), } }); </ins> err.help(&format!("the following implementations were found:{}{}", <del> &impl_candidates[0..end].iter().map(|candidate| { format!("n  {:?}", candidate) }).collect::<String>(), </del> <ins> &impl_candidates[0..end].iter().map(normalize).collect::<String>(), </ins> if impl_candidates.len() > 5 { format!("nand {} others", impl_candidates.len() - 4) } else {

Discussion:
After , when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like: Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.
I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple
It only appears if you explicitly disambiguate the trait, like . .
are you displaying these as ? I feel that'd be a reasonable output for this.
that would be a better fallback than , but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)
That's better in some ways, but kinda implies that
Change:
debug!("binders({:?}: {:?}, ambient_variance={:?})", a, b, self.ambient_variance); <ins> if !a.skip_binder().has_escaping_bound_vars() && !b.skip_binder().has_escaping_bound_vars() { // Fast path for the common case. self.relate(a.skip_binder(), b.skip_binder())?; return Ok(a.clone()); } </ins> if self.ambient_covariance() { // Covariance, so we want `for<..> A <: for<..> B` -- // therefore we compare any instantiation of A (i.e., A

Discussion:
The following takes approximately one year to compile: (This estimate was derived from observing that compile time scales seemingly exponentially in the depth of the instantiated closure. At level 23 it took about 25 seconds, and at 22 only 13. Extrapolating this doubling-per-depth leads us to about a year at level 43 which is depicted above).
Flamegraph:
Yields: cc
Change:
fn collect_enum_variants(&mut self, def_id: DefId) -> Option<Vec<Path>> { self.find_module(def_id).map(|(enum_module, enum_import_suggestion)| { let mut variants = Vec::new(); <del> enum_module.for_each_child_stable(self.r, |_, ident, _, name_binding| { </del> <ins> enum_module.for_each_child(self.r, |_, ident, _, name_binding| { </ins> if let Res::Def(DefKind::Variant, _) = name_binding.res() { let mut segms = enum_import_suggestion.path.segments.clone(); segms.push(ast::PathSegment::from_ident(ident));

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.