jiebi/CodeConvo huggingface dataset:
Change:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:

Discussion:
/// /// let os_str = OsStr::new("foo"); /// ``` <ins> #[inline] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn new<S: AsRef<OsStr> + ?Sized>(s: &S) -> &OsStr { s.as_ref() } <ins> #[inline] </ins> fn from_inner(inner: &Slice) -> &OsStr { unsafe { &*(inner as *const Slice as *const OsStr) } }

/// /// Note: it is *crucial* that this API is private, to avoid /// revealing the internal, platform-specific encodings. <ins> #[inline] </ins> fn bytes(&self) -> &[u8] { unsafe { &*(&self.inner as *const _ as *const [u8]) } }

#[stable(feature = "rust1", since = "1.0.0")] impl PartialEq for OsStr { <ins> #[inline] </ins> fn eq(&self, other: &OsStr) -> bool { self.bytes().eq(other.bytes()) }

#[stable(feature = "rust1", since = "1.0.0")] impl PartialEq<str> for OsStr { <ins> #[inline] </ins> fn eq(&self, other: &str) -> bool { *self == *OsStr::new(other) }

#[stable(feature = "rust1", since = "1.0.0")] impl PartialEq<OsStr> for str { <ins> #[inline] </ins> fn eq(&self, other: &OsStr) -> bool { *other == *OsStr::new(self) }

#[stable(feature = "rust1", since = "1.0.0")] impl AsRef<OsStr> for str { <ins> #[inline] </ins> fn as_ref(&self) -> &OsStr { OsStr::from_inner(Slice::from_str(self)) }

#[stable(feature = "rust1", since = "1.0.0")] impl AsRef<OsStr> for String { <ins> #[inline] </ins> fn as_ref(&self) -> &OsStr { (&**self).as_ref() }

} impl Slice { <ins> #[inline] </ins> pub fn from_str(s: &str) -> &Slice { unsafe { mem::transmute(Wtf8::from_str(s)) } }

} impl Slice { <ins> #[inline] </ins> fn from_u8_slice(s: &[u8]) -> &Slice { unsafe { mem::transmute(s) } } <ins> #[inline] </ins> pub fn from_str(s: &str) -> &Slice { Slice::from_u8_slice(s.as_bytes()) }
Change:
This code () produces ICE on current beta and nightly
Tagging as P-medium and "triaged" for async-await. Note that yield is unstable.
the feature is nightly but the ice doesn't require any feature gate to trigger.
searched nightlies: from nightly-2019-01-01 to nightly-2020-02-01 regressed nightly: nightly-2019-09-29 searched commits: from to regressed commit: source code: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
thanks for the bisection! Annoyingly, it regressed in a rollup PR, which means there are many candidates: (Docs: slice elements are equidistant) -- (Include message on tests that should panic but do not) -- (Remove stray references to the old global tcx) -- (Remove unused DepTrackingMap) -- (Account for tail expressions when pointing at return type) -- (hir: Disallow on constants) -- (Fix divduration() marked as stable by mistake) -- (update rtpSpawn's parameters type(It's prototype has been updated in libc)) -- (Thou shallt not ) -- (Stabilize mapgetkeyvalue feature) -- ( fix links to primitives in documentation) -- (Upgrade envlogger to 0.7) -- (Add mailmap entry for Dustin Bensing by request) -- (check_match: improve diagnostics for with ) --
If I had to guess, I would guess (cc triggered this regression, but or are possibilities. I would guess because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE. If indeed I am correct, then this could be fixed by adding a call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).

Discussion:
use rustc_hir::itemlikevisit::ItemLikeVisitor; use rustc_hir::{HirId, ItemLocalId}; <del> pub fn check_crate(hir_map: &Map<'_>) { </del> <ins> pub fn check_crate(hir_map: &Map<'_>, sess: &rustc_session::Session) { </ins> hir_map.dep_graph.assert_ignored(); let errors = Lock::new(Vec::new());

if !errors.is_empty() { let message = errors.iter().fold(String::new(), |s1, s2| s1 + "n" + s2); <del> bug!("{}", message); </del> <ins> sess.delay_span_bug(rustc_span::DUMMY_SP, &message); </ins> } }

let map = Map { krate, dep_graph, crate_hash, map, hir_to_node_id, definitions }; sess.time("validate_HIR_map", || { <del> hir_id_validator::check_crate(&map); </del> <ins> hir_id_validator::check_crate(&map, sess); </ins> }); map

<ins> #![feature(generators)] // edition:2018 // Regression test for #67158. fn main() { async { yield print!(":C") }; //~ ERROR `async` generators are not yet supported } </ins>

<ins> error[E0727]: `async` generators are not yet supported --> $DIR/async-generator-issue-67158.rs:5:13 | LL |     async { yield print!(":C") }; |             ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0727`. </ins>
Change:
gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler

Discussion:
fn report(&mut self, error: GroupedMoveError<'tcx>) { let (mut err, err_span) = { <del> let (span, original_path, kind): (Span, &Place<'tcx>, &IllegalMoveOriginKind<'_>) = </del> <ins> let (span, use_spans, original_path, kind,): ( Span, Option<UseSpans>, &Place<'tcx>, &IllegalMoveOriginKind<'_>, ) = </ins> match error { GroupedMoveError::MovesFromPlace { span, ref original_path, ref kind, .. } | GroupedMoveError::MovesFromValue { span, ref original_path, ref kind, .. } => { <del> (span, original_path, kind) </del> <ins> (span, None, original_path, kind) </ins> } GroupedMoveError::OtherIllegalMove { use_spans, ref original_path, ref kind } => { <del> (use_spans.args_or_use(), original_path, kind) </del> <ins> (use_spans.args_or_use(), Some(use_spans), original_path, kind) </ins> }, }; debug!("report: original_path={:?} span={:?}, kind={:?} 

original_path, target_place, span, <ins> use_spans, </ins> ) } IllegalMoveOriginKind::InteriorOfTypeWithDestructor { container_ty: ty } => {

move_place: &Place<'tcx>, deref_target_place: &Place<'tcx>, span: Span, <ins> use_spans: Option<UseSpans>, </ins> ) -> DiagnosticBuilder<'a> { // Inspect the type of the content behind the // borrow to provide feedback about why this

if let Ok(snippet) = self.infcx.tcx.sess.source_map().span_to_snippet(span) { let is_option = move_ty.starts_with("std::option::Option"); let is_result = move_ty.starts_with("std::result::Result"); <del> if is_option || is_result { </del> <ins> if (is_option || is_result) && use_spans.map_or(true, |v| !v.for_closure()) { </ins> err.span_suggestion( span, &format!("consider borrowing the `{}`'s content", if is_option {

<ins> struct NotCopyable; fn func<F: FnMut() -> H, H: FnMut()>(_: F) {} fn parse() { let mut var = None; func(|| { // Shouldn't suggest `move ||.as_ref()` here move || { //~^ ERROR: cannot move out of `var` var = Some(NotCopyable); } }); } fn main() {} </ins>

<ins> error[E0507]: cannot move out of `var`, a captured variable in an `FnMut` closure --> $DIR/option-content-move2.rs:9:9 | LL |     let mut var = None; |         ------- captured outer variable ... LL |         move || { |         ^^^^^^^ move out of `var` occurs here LL | LL |             var = Some(NotCopyable); |             --- |             | |             move occurs because `var` has type `std::option::Option<NotCopyable>`, which does not implement the `Copy` trait |             move occurs due to use in closure error: aborting due to previous error For more information about this error, try `rustc --explain E0507`. </ins>
Change:
The comments are quite old and probably need some small updates to reflect having been removed from the language. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think I should be able to handle this. Hopefully some time in the next few days. Am I right in thinking I just do this? claim I've found the documentation style RFC, and some info about what was, which should hopefully be enough info to improve this comment. If there's anything else specific I should consider plz let me know.
Yes, you can definitely just do this and any questions which come up can be addressed on the (eventual) PR most likely. I imagine it's mostly a matter of just deleting related documentation; if you want to try and replace it with something more up to date that would be even better.

Discussion:
//! The AST pointer. //! <del> //! Provides `P<T>`, a frozen owned smart pointer, as a replacement for `@T` in //! the AST. </del> <ins> //! Provides `P<T>`, a frozen owned smart pointer. </ins> //! //! # Motivations and benefits //! //! * **Identity**: sharing AST nodes is problematic for the various analysis //!   passes (e.g., one may be able to bypass the borrow checker with a shared <del> //!   `ExprKind::AddrOf` node taking a mutable borrow). The only reason `@T` in the //!   AST hasn't caused issues is because of inefficient folding passes which //!   would always deduplicate any such shared nodes. Even if the AST were to //!   switch to an arena, this would still hold, i.e., it couldn't use `&'a T`, //!   but rather a wrapper like `P<'a, T>`. </del> <ins> //!   `ExprKind::AddrOf` node taking a mutable borrow). </ins> //! //! * **Immutability**: `P<T>` disallows mutating its inner `T`, unlike `Box<T>` //!   (unless it contains an `Unsafe` interior, but that may be denied later).
Change:
I saw this failure in rayon CI: I'm on Linux, but I tried this build under Wine: It seems intention in was that this should be statically linked, but that was clobbered by in at least. The same error occurs on (via Wine again for me).
Probably the culprit is here:
As immediate workaround I suggest adding to the PATH, it should be installed on most of the Windows CI.
Thanks! It works.
triage: P-high, has PR, removing nomination.
Sadly, that didn't work for me: "The procedure entry point ZNSt13futurebase12ResultbaseC2Ev could not be located in the dynamic link library C:Usersxxx.rustuptoolchainsnightly-x8664-pc-windows-gnubinrustcdriver-" Just posting as an FYI, not expecting a solution.
FWIW it was fixed in nightly but not yet in beta.
Did this fix make it into stable? I'm getting that error in rustc 1.59.0 ( 2022-02-23). Cross-compiling from Linux: Trying to run under Wine 7.0. Wine error messages: Please, statically link this stuff. (Trying to find the correct version of . MinGW has four different versions. Correct versions seem to be the ones in 9.3.win32)
It was linked statically in the past, must be regression. Does it work on other versions for you? There are 2 versions shipped in Ubuntu: posix and win32. Posix is the correct one. BTW those libraries come from GCC, not MinGW.
Upon closer inspection you are not having problem running rustc but with artifacts built with rustc. In this case this entirely different issue and you need to find which crate in your dependency tree has linked dynamic libstdc++.
Yes. I was using a deprecated package that pulled in some DLLs. Once I got rid of that package, the problem disappeared.
two questions: 1) how did you find the offending package, 2) which one was it? I'm getting the same thing on
Looked through the build logs with "grep" for the package name.
I couldn't find a specific dependency that caused the issue, but upgrading rust from to fixed it for me.

Discussion:
// not for MSVC or macOS if builder.config.llvm_static_stdcpp && !target.contains("freebsd") && <del> !target.contains("windows") && </del> <ins> !target.contains("msvc") && </ins> !target.contains("apple") { let file = compiler_file(builder, builder.cxx(target).unwrap(),
Change:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

Discussion:
let span = self.tcx.def_span(generator_did); // Do not ICE on closure typeck (#66868). <del> if let None = self.tcx.hir().as_local_hir_id(generator_did) { </del> <ins> if self.tcx.hir().as_local_hir_id(generator_did).is_none() { </ins> return false; }

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Const<const N: usize>; impl<const C: usize> Const<{C}> { fn successor() -> Const<{C + 1}> { Const } } fn main() { let _x: Const::<2> = Const::<1>::successor(); } </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61747.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

<ins> // check-pass #![allow(incomplete_features, dead_code, unconditional_recursion)] #![feature(const_generics)] fn fact<const N: usize>() { fact::<{ N - 1 }>(); } fn main() {} </ins>

<ins> // Fixed by #67160 trait Trait1 { type A; } trait Trait2 { type Type1<B>: Trait1<A=B>; //~^ ERROR: generic associated types are unstable //~| ERROR: type-generic associated types are not yet implemented } fn main() {} </ins>

<ins> error[E0658]: generic associated types are unstable --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error: type-generic associated types are not yet implemented --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

<ins> // Regression test for #66270, fixed by #66246 struct Bug { incorrect_field: 0, //~^ ERROR expected type } struct Empty {} fn main() { let Bug { any_field: Empty {}, } = Bug {}; } </ins>

<ins> error: expected type, found `0` --> $DIR/issue-66270-pat-struct-parser-recovery.rs:4:22 | LL |     incorrect_field: 0, |                      ^ expected type error: aborting due to previous error </ins>
Change:
Repro rustc 1.40.0 ( 2019-12-16) , the resulting wasm file doesn't have the symbol . But if we compile with , the symbol is correctly exported in the wasm file. Expected behavior: Public static variables should get exported by default. We believe this is a regression from 1.39.0. Does correctly export static variables.
cc
Symbols for wasm are and it looks like no flag is passed for , which is the bug. It looks like this may trace back to not including statics, but that's just a guess. I don't personally have time to deeply investigate this right now.
After a some investigation: disables , which means all the symbols are exported. This is why appears. If is set, symbols have to be exported , which is not the case for as has stated above The reason for this is is false. is a rust symbol and we export to a c lib. Statics are explicitly marked as . It is unclear to me how this should be handled. Maybe statics should be exported with if the static is a number? I'll make a PR for it, that might be a better place to talk about implementation details.
Oh good find! I'm not sure about emscripten, but wasm has changed in the meantime so that it can export statics, so the wasm case there I believe can be removed.

Discussion:
if is_extern && !std_internal { let target = &tcx.sess.target.target.llvm_target; // WebAssembly cannot export data symbols, so reduce their export level <del> if target.contains("wasm32") || target.contains("emscripten") { </del> <ins> if target.contains("emscripten") { </ins> if let Some(Node::Item(&hir::Item { kind: hir::ItemKind::Static(..), .. })) = tcx.hir().get_if_local(sym_def_id) {

#[no_mangle] pub extern fn foo() {} <ins> #[no_mangle] pub static FOO: u64 = 42; </ins>

const my_exports = {}; let nexports = 0; for (const entry of list) { <del> if (entry.kind !== 'function') continue; my_exports[entry.name] = true; nexports += 1; </del> <ins> if (entry.kind == 'function'){ nexports += 1; } my_exports[entry.name] = entry.kind; </ins> } <del> if (my_exports.foo === undefined) </del> <ins> if (my_exports.foo != "function") </ins> throw new Error("`foo` wasn't defined"); <ins> if (my_exports.FOO != "global") throw new Error("`FOO` wasn't defined"); </ins> if (my_exports.main === undefined) { if (nexports != 1) throw new Error("should only have one function export");
Change:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form

Discussion:
fn print_associated_type( &mut self, ident: ast::Ident, <ins> generics: &ast::Generics, </ins> bounds: &ast::GenericBounds, ty: Option<&ast::Ty>, ) { self.word_space("type"); self.print_ident(ident); <ins> self.print_generic_params(&generics.params); </ins> self.print_type_bounds(":", bounds); <ins> self.print_where_clause(&generics.where_clause); </ins> if let Some(ty) = ty { self.s.space(); self.word_space("=");

self.print_fn_full(sig, item.ident, &item.generics, &item.vis, body, &item.attrs); } ast::AssocItemKind::TyAlias(bounds, ty) => { <del> self.print_associated_type(item.ident, bounds, ty.as_deref()); </del> <ins> self.print_associated_type(item.ident, &item.generics, bounds, ty.as_deref()); </ins> } ast::AssocItemKind::Macro(mac) => { self.print_mac(mac);

fn print_associated_type( &mut self, ident: ast::Ident, <ins> generics: &hir::Generics<'_>, </ins> bounds: Option<hir::GenericBounds<'_>>, ty: Option<&hir::Ty<'_>>, ) { self.word_space("type"); self.print_ident(ident); <ins> self.print_generic_params(&generics.params); </ins> if let Some(bounds) = bounds { self.print_bounds(":", bounds); } <ins> self.print_where_clause(&generics.where_clause); </ins> if let Some(ty) = ty { self.s.space(); self.word_space("=");

hir::TraitItemKind::Type(ref bounds, ref default) => { self.print_associated_type( ti.ident, <ins> &ti.generics, </ins> Some(bounds), default.as_ref().map(|ty| &**ty), );

self.ann.nested(self, Nested::Body(body)); } hir::ImplItemKind::TyAlias(ref ty) => { <del> self.print_associated_type(ii.ident, None, Some(ty)); </del> <ins> self.print_associated_type(ii.ident, &ii.generics, None, Some(ty)); </ins> } hir::ImplItemKind::OpaqueTy(bounds) => { self.word_space("type");

<ins> // Check that associated types print generic parameters and where clauses. // See issue #67509. // pretty-compare-only // pp-exact:gat-bounds.pp #![feature(generic_associated_types)] trait X { type Y<T>: Trait where Self: Sized; } impl X for () { type Y<T> where Self: Sized = u32; } fn main() { } </ins>
Change:
The feature which allows for patterns, is implemented in The PR doesn't have as good coverage of the dynamic semantics as we might like. Once the PR lands, we should try to improve things before we stabilize the feature. Notable tests to include: [x] Dynamic drop () cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is now unblocked as has landed.
I would like to work on this one
Go for it :) assign
Now that has landed, I think we can close this once also lands.

Discussion:
#![feature(generators, generator_trait, untagged_unions)] #![feature(move_ref_pattern)] <ins> #![feature(bindings_after_at)] </ins> #![allow(unused_assignments)] #![allow(unused_variables)]

} } <ins> fn bindings_after_at_dynamic_init_move(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; let _x; if let bar @ Some(_) = foo { _x = bar; } } fn bindings_after_at_dynamic_init_ref(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; let _x; if let bar @ Some(_baz) = &foo { _x = bar; } } fn bindings_after_at_dynamic_drop_move(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; if let bar @ Some(_) = foo { bar } else { None }; } fn bindings_after_at_dynamic_drop_ref(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; if let bar @ Some(_baz) = &foo { bar } else { &None }; } </ins> fn move_ref_pattern(a: &Allocator) { let mut tup = (a.alloc(), a.alloc(), a.alloc(), a.alloc()); let (ref _a, ref mut _b, _c, mut _d) = tup;

run_test(|a| panic_after_init_temp(a)); run_test(|a| panic_after_init_by_loop(a)); <ins> run_test(|a| bindings_after_at_dynamic_init_move(a, true)); run_test(|a| bindings_after_at_dynamic_init_move(a, false)); run_test(|a| bindings_after_at_dynamic_init_ref(a, true)); run_test(|a| bindings_after_at_dynamic_init_ref(a, false)); run_test(|a| bindings_after_at_dynamic_drop_move(a, true)); run_test(|a| bindings_after_at_dynamic_drop_move(a, false)); run_test(|a| bindings_after_at_dynamic_drop_ref(a, true)); run_test(|a| bindings_after_at_dynamic_drop_ref(a, false)); </ins> run_test_nopanic(|a| union1(a)); }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

Discussion:
[[package]] name = "cargo" <del> version = "0.42.0" </del> <ins> version = "0.43.0" </ins> dependencies = [ "atty", "bytesize",

[[package]] name = "git2" <del> version = "0.10.1" </del> <ins> version = "0.11.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "39f27186fbb5ec67ece9a56990292bc5aed3c3fc51b9b07b0b52446b1dfb4a82" </del> <ins> checksum = "77519ef7c5beee314d0804d4534f01e0f9e8d9acdee2b7a48627e590b27e0ec4" </ins> dependencies = [ "bitflags", "libc",

[[package]] name = "git2-curl" <del> version = "0.11.0" </del> <ins> version = "0.12.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "cd6527e480187ce19aaf4fa6acfb7657b25628ce31cb8ffabdfca3bf731524c5" </del> <ins> checksum = "d2559abb1d87d27668d31bd868a000f0e2e0065d10e78961b62da95d7a7f1cc7" </ins> dependencies = [ "curl", "git2",

[[package]] name = "libgit2-sys" <del> version = "0.9.1" </del> <ins> version = "0.10.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "a30f8637eb59616ee3b8a00f6adff781ee4ddd8343a615b8238de756060cc1b3" </del> <ins> checksum = "d9ec6bca50549d34a392611dde775123086acbd994e3fff64954777ce2dc2e51" </ins> dependencies = [ "cc", "libc",

<del> Subproject commit 19a0de242f442ac7149c511031599aafa35b36dc </del> <ins> Subproject commit 86134e7666a088682f20b76278c3ee096a315218 </ins>

<del> Subproject commit cfb332005845883f2abb50fe183fc91221bad9d1 </del> <ins> Subproject commit c807fbc8ba41432388b6f590668ba81314c07c32 </ins>