jiebi/CodeConvo huggingface dataset:
Code change:
// These cases don't actually need a destination ExprKind::Assign { .. } | ExprKind::AssignOp { .. } <del> | ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::LlvmInlineAsm { .. } | ExprKind::Return { .. } => { </del> <ins> | ExprKind::LlvmInlineAsm { .. } => { </ins> unpack!(block = this.stmt_expr(block, expr, None)); this.cfg.push_assign_unit(block, source_info, destination, this.hir.tcx()); block.unit() } <ins> ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::Return { .. } => { unpack!(block = this.stmt_expr(block, expr, None)); // No assign, as these have type `!`. block.unit() } </ins> // Avoid creating a temporary ExprKind::VarRef { .. } | ExprKind::SelfRef

Related discussion:
text: <!-- 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. --The code fails to pass <!-- 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. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.
Code change:
call_locations, no_emit_shared: false, html_no_source, <del> force_unstable_if_unmarked, </del> }; Some((options, render_options)) }

Related discussion:
text: for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you
Code change:
return f.c; } <ins> struct quad_floats { float a; float b; float c; float d; }; float get_c_exhaust_sysv64_ints( void *a, void *b, void *c, void *d, void *e, void *f, // `f` used the last integer register, so `g` goes on the stack. // It also used to bring the "count of available integer registers" down to // `-1` which broke the next SSE-only aggregate argument (`h`) - see #62350. void *g, struct quad_floats h ) { return h.c; } </ins> // Calculates the average of `(x + y) / n` where x: i64, y: f64. There must be exactly n pairs // passed as variadic arguments. There are two versions of this function: the // variadic one, and the one that takes a `va_list`.

Related discussion:
text: We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).
Code change:
return f.c; } <ins> struct quad_floats { float a; float b; float c; float d; }; float get_c_exhaust_sysv64_ints( void *a, void *b, void *c, void *d, void *e, void *f, // `f` used the last integer register, so `g` goes on the stack. // It also used to bring the "count of available integer registers" down to // `-1` which broke the next SSE-only aggregate argument (`h`) - see #62350. void *g, struct quad_floats h ) { return h.c; } </ins> // Calculates the average of `(x + y) / n` where x: i64, y: f64. There must be exactly n pairs // passed as variadic arguments. There are two versions of this function: the // variadic one, and the one that takes a `va_list`.

Related discussion:
text: Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway
Code change:
"checksum quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)" = "7a6e920b65c65f10b2ae65c831a81a073a89edd28c7cce89475bff467ab4167a" "checksum quote 0.6.12 (registry+https://github.com/rust-lang/crates.io-index)" = "faf4799c5d274f3868a4aae320a0a182cbd2baee377b378f080e16a23e9d80db" "checksum racer 2.1.23 (registry+https://github.com/rust-lang/crates.io-index)" = "94dbdea3d959d8f76a2e303b3eadf107fd76da886b231291e649168613d432fb" <del> "checksum rand 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "552840b97013b1a26992c11eac34bdd778e464601a4c2054b5f0bff7c6761293" </del> "checksum rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ae9d223d52ae411a33cf7e54ec6034ec165df296ccd23533d671a28252b6f66a" "checksum rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "771b009e3a508cb67e8823dda454aaa5368c7bc1c16829fb77d3e980440dd34a" "checksum rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0905b6b7079ec73b314d4c748701f6931eb79fd97c668caa3f1899b22b32c6db"

Related discussion:
text: I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.
Code change:
"checksum quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)" = "7a6e920b65c65f10b2ae65c831a81a073a89edd28c7cce89475bff467ab4167a" "checksum quote 0.6.12 (registry+https://github.com/rust-lang/crates.io-index)" = "faf4799c5d274f3868a4aae320a0a182cbd2baee377b378f080e16a23e9d80db" "checksum racer 2.1.23 (registry+https://github.com/rust-lang/crates.io-index)" = "94dbdea3d959d8f76a2e303b3eadf107fd76da886b231291e649168613d432fb" <del> "checksum rand 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "552840b97013b1a26992c11eac34bdd778e464601a4c2054b5f0bff7c6761293" </del> "checksum rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ae9d223d52ae411a33cf7e54ec6034ec165df296ccd23533d671a28252b6f66a" "checksum rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "771b009e3a508cb67e8823dda454aaa5368c7bc1c16829fb77d3e980440dd34a" "checksum rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0905b6b7079ec73b314d4c748701f6931eb79fd97c668caa3f1899b22b32c6db"

Related discussion:
text: That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps
Code change:
target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,

Related discussion:
text: A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now.
Code change:
target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,

Related discussion:
text: It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
Code change:
target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,

Related discussion:
text: refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.
Code change:
python2.7 "$BUILD_SOURCESDIRECTORY/src/tools/publish_toolstate.py" "$(git rev-parse HEAD)" "$(git log --format=%s -n1 HEAD)" "" "" cd .. rm -rf rust-toolstate <del> condition: and(succeeded(), eq(variables['IMAGE'], 'mingw-check')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), eq(variables['IMAGE'], 'mingw-check')) </ins> displayName: Verify the publish_toolstate script works - bash: |

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
#![crate_name = "foo"] <del> // The goal of this test is to answer that it won't be generated as a list because </del> <ins> // The goal of this test is to ensure that it won't be generated as a list because </ins> // block doc comments can have their lines starting with a star. // @has foo/fn.foo.html

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
<del> error[E0271]: type mismatch resolving `<Empty<_> as Stream>::Item == Repr` --> $DIR/issue-89008.rs:38:43 | LL |     fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { |                        ----               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type mismatch resolving `<Empty<_> as Stream>::Item == Repr` |                        | |                        this type parameter | note: expected this to be `()` --> $DIR/issue-89008.rs:17:17 | LL |     type Item = (); |                 ^^ = note:   expected unit type `()` found type parameter `Repr` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </del>

Related discussion:
text: <!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.