jiebi/CodeConvo huggingface dataset:
Code change:
// @matches foo/fn.function_with_a_really_long_name.html '//*[@class="rust item-decl"]//code' " //     function_with_a_really_long_name(n //        parameter_one: i32,n <del> //        parameter_two: i32n </del> <ins> //        parameter_two: i32,n </ins> //    ) -> Option<i32>$" pub fn function_with_a_really_long_name(parameter_one: i32, parameter_two: i32) -> Option<i32> { Some(parameter_one + parameter_two)

Related discussion:
text: Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1

Related discussion:
text: The AVR-Rust post continues to track AVR-LLVM, which is tracking upstream LLVM. That means we are running into changes from the future LLVM 4.0. I figured we could open up this issue now to track the changes required to stay compatible. This is the current list of upgrade hazards. Note that some of the text may be nonsensical as I don't truly grok all the internals of LLVM so some changes are wild stabs in the dark. It's also possible that some failed fix for earlier problems actually caused later problems: [x] DIDescriptorFlags became a real C++ enum and not a bitset () [x] An EH personality is required for every function that can unwind () [x] pass changed header and constructor name () [x] changed API () [x] Bitcode/ReaderWriter.h has been renamed / API changed () () [x] changed API () [x] changed API () [x] prefers over () [x] string type changes () [x] is not guaranteed to be null terminated () [x] changed return types () [x] Archive support changed error handling types () [x] Teach Rust about an LLVM 4.0 API change for creating debug info for global variables () [x] Check all errors in LLVMRustArchiveIterator API () [x] Upgrade emscripten (kripken/emscripten-fastcomp, kripken/emscripten-fastcomp-clang) [x] Alignment now represented with 32 bits instead of 64 () [x] API changed again () [x] now takes an instead of a and () [x] Symbol lookup error when linking dylibs () [x] Undefined behavior in tests () [x] Unoptimised builds of compilerbuiltins on ARM have references to () A WIP PR that performs the upgrade! Some issues whose resolution is believed to be blocked on LLVM 4.0: [ ]
Next time we do this upgrade we'll need emscripten to do it to. It would be good if we could pull in a working llvm wasm backend in the same upgrade, but that may not be ready before the end of the year.
For the record, I am also working with a fork of LLVM that is tracking upstream (not AVR-LLVM but similar in spirit) and am starting to work on this now.
Code change:
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1

Related discussion:
text: I'm looking through the AVR-Rust commits and I'd love to coordinate --- feel free to ping me on IRC () or via mail!
Note that there is a regression reported against llvm 4.0 regarding the powi intrinsic on armhf targets: I'm explicitly mentioning this here, because there were previously problems with it, see and related issues. Also cc rust-lang-nursery/compiler-builtins, an issue about the same problem in the compiler-rt rust port.
To clarify what I think the is referring to (correct me if I'm wrong) In LLVM 3.9 and before, the calling convention LLVM used with the powidf2 and powisf2 intrinsics was basically the C calling convention In LLVM 4.0, the backend was corrected to expect these intrinsics to have the aapcs calling convention One person that aapcs is expected for powis2f and powid2f, while another a claiming that the normal C calling convention should be used. So it seems that if the LLVM change is not reverted (expected powisf2 to be aapcs) then we need to update our definition. This is going to be a huge PITA for supporting multiple LLVM versions as well. We need to select the calling convention depending on the LLVM version as well...
Any objections to doing that coordination here on GitHub, or on one of our forks?
I don't have strong preferences for the communication channel.
should address what is listed as API changes" above (the core of the change is in how attributes are represented).
I would prefer to upstream LLVM 4.0 compatibility patches sooner rather than later. That includes my own work obviously, but I'm also looking at the commits I cherry-picked from AVR-Rust. In particular, looks like a reasonable simplification even independent of LLVM 4.0 compatibility, and looks like a nice little self-contained fix. Could you create PRs for those? (If you don't have the time but are otherwise fine with upstreaming, I'd be happy to manage that, giving proper credit of course.)
Absolutely! I wasn't really sure how much we could expect LLVM 4 to change as it goes towards stable / how much churn the Rust maintainers would want to put up with. I'll get those pulled out and submitted soon. I think I'm also starting to understand some of the silly error handling that the new LLVM does.
Code change:
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1

Related discussion:
text: Awesome, thanks in advance!
BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of
Does anyone have ETA? I'd like to know when I can use AVR. :)
You should follow along at avr-rust/rust for the AVR-specific issues. Upgrading to LLVM 4 will not magically yield AVR support.
Ok, thank you!
I've created for the API change.
I've also created for another debug info API change.
After putting all of those patches on top of master, was successfully built. I got several undefined references, most likely due to my local LLVM setup.
I think the next step after all those patches land is to allow LLVM 4.0 in the configure/rustbuild scripts and then actually update the submodule.
We'll also need to fix that AAPCS bug first, I just noticed it
Don't forget : I think that means that the Rust fork of LLVM is following the Emscripten fork of LLVM, thus Emscripten needs to upgrade to LLVM 4.0 / master before Rust can.
And I'm hoping to supersede it with
I just ran into which changed the alignment from u64 to u32. Will think about a proper fix later, unless someone beats me to it (but should merge first to avoid further conflicts).
And it says So, that will be "exciting".
Is there much left blocking an upgrade?
This: Has to be done too but I don't know if it's currently being worked on. Any info on that ^?
No nobody is actively working on an emscripten upgrade. Since even when that is done it will probably take a lot of work to land an LLVM upgrade, there's probably more we can do to prepare. Once we decide we want to do it, somebody can prepare a patch to throw at the bots. It seems likely stuff will not work and it will be a slog to fix it all, which will give us time. We don't need emcc to generate wasm stds, just a fairly small patch on our LLVM branch that will hopefully port without much difficulty. So if somebody feels motivated, it's not too soon to start going after it. As to the emscripten upgrade, we should at least let know that we're starting to think seriously about doing the upgrade, and need emscripten to upgrade LLVM too.
Code change:
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1

Related discussion:
text: It seems like that could be a big effort. Another alternative is to use the LLVM wasm backend, but I still have not heard that it is generally usable yet. cc
I can look into the effort needed to update emscripten's fastcomp LLVM version, but I need to know a commit to aim for. Sounds like the goal here is 4.0, which hasn't released yet, so I guess I have to wait on that?
So far as AVR is concerned, any commit within the last month will do. There will likely be a few more months until 4.0 is actually tagged (every ~6 months a new release is made). It is quite common for projects to track LLVM master, which I'm personally a fan of.
But is it common to release snapshots from LLVM master? When LLVM itself only releases every 6 months, it seems incongruous for Rust to pick arbitrary snapshots in its 6-week release cycle.
LLVM 4.0 will branch in a week and the final release will happen in late feburary (schedule says 21st for final tag, but this is flexible IIRC).
From the llvm-dev mailing list:
branch has happened
An update on the "powidf2 / powisf2 calling convention changed" situation: The regression has been fixed on llvm master () however from what I can tell the fixes are not yet in the 4.0 branch, although the fix may be backported ().
I've started working on updating emscripten kripken/emscripten-fastcomp kripken/emscripten-fastcomp-clang I've also created a new bug requesting that the regression fix be merged into 4.0 .
says the emcc LLVM upgrade is ready to go. or are we prepared to begin the Rust LLVM upgrade? I think what needs to happen is to submit the Rust PR and start throwing it against the bots. Once it looks like that is close to landing then we'll have to coordinate both project's upgrades to minimize the breakage window where rustc and emcc have different backends. I'm not sure how best to do that - we might just try to upgrade as simultaneously as possible and accept up to a few days of breakage, or we might ask emscripten to stage their build such that they can swap their incoming branch right after we land to master.
Code change:
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1

Related discussion:
text: needs to know the exact LLVM commit we're moving to as well, and that will become clear once the PR starts working through the queue. The stars are aligning. Let's make this happen. Thanks for doing the fastcomp upgrade.
We are not fully compatible with LLVM 4.0. I have heard from at least one person (on IRC) that building against stock LLVM 4.0 (RC) does not work. I haven't personally inspected all failures, but there's at least two things still missing: (and possibly ). It shouldn't be a conceptually difficult patch to apply the equivalent changes to rustc, but possibly a big diff. I haven't digested the implications yet, but it might be a relatively simple change localized to the function in that currently calls .
The fix has been merged into the 4.0 release (). I'm going to try and build Rust against stock LLVM 4.0 and figure out what needs modifying.
On top of what mentioned: now takes an instead of a and ()
I've got a half-baked patch to use the new signature for I'm not familiar enough with Rust internals to finish it off. I ran into a problem in as it is given a but in order to use we need a . We need to call in order to build an instance of .
I've opened for the change that mentioned. I've also opened for the 32-bit alignment change. I believe that is the only thing we need to update aside from these two PRs in order to get the compiler to successfully be built with LLVM 4.0.
So to summarize where we are with LLVM 4 (correct me if I'm wrong): 4.0 will be released in about 1 week (2/21). are no known issues with supporting LLVM 4.0, but there are probably issues that will be discovered once we try to use it in nightlies. runs on in-tree LLVM + LLVM 3.7 (so PRs haven't actually been tested on LLVM 4.0 yet). support LLVM back to ~3.6(?
Code change:
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1

Related discussion:
text: )~ 3.7 and will continue to support it until either: a. It's so old that it can be removed without bothering package maintainers b. We need at least version X in order to fix an important bug c. The API is so different from version Y that it's a huge pain to support will open a PR to update the submodule shortly after release but it will take a month to land due to: a. Waiting for emscripten ( -) b. Bugs in upstream c. Missed LLVM API changes d. Making bors happy e. All of the above
Thanks for the summary The only correction I'd make is that in your point (4) you can s/3.6/3.7/, but otherwise it's accurate :) If you'd like to start preparing a PR to update to LLVM 4.0 I don't think we need to block waiting for LLVM itself to release 4.0. Currently only one Travis builder runs on each PR but we could temporarily allow more builders running on an LLVM 4.0 PR to start weeding out bugs before it hits
I gave it a go but I don't think my git-fu (or patience) is strong enough to handle a big merge like this. What I can do is try to run rustc with upstream LLVM and file/fix issues as I find them. There is at least one issue remaining as of (details to come).
Whoever ends up doing the LLVM upgrade, please also upgrade the compiler-rt submodule so that the sanitizer related LLVM passes don't diverge from what the sanitizer runtimes expect.
In fact, if you upgrade before the release, they usually mention your project in the release notes. :)
So whats the next issue(s) to subscribe to in the race-to-AVR? :)
As says on , we can integrate the latest Rust master into the avr-rust compiler. After that, we can spend some time getting compiling for AVR. Once that is working, we could then start looking into upstreaming the AVR target to Rust.
AVR-specific issues can be raised / tracked in For example, there are two that I'm aware of right now:
has been closed, so that can be checked off in the top post.
Code change:
use cortex_m_rt::entry; use cortex_m_semihosting as semihosting; <del> //FIXME: This imports the provided #[panic_handler]. #[allow(rust_2018_idioms)] extern crate panic_halt; entry!(main); </del> <ins> use panic_halt as _; #[entry] </ins> fn main() -> ! { let x = 42;

Related discussion:
text: I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.
Code change:
// We couldn't calculate the span of the markdown block that had the error, so our // diagnostics are going to be a bit lacking. let mut diag = self.cx.sess().struct_span_warn( <del> super::span_of_attrs(&item.attrs), </del> <ins> super::span_of_attrs(&item.attrs).unwrap_or(item.source.span()), </ins> "doc comment contains an invalid Rust code block", );

Related discussion:
text: crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .