jiebi/CodeConvo huggingface dataset:
Code change:
COPY host-x86_64/dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh COPY host-x86_64/dist-various-2/build-solaris-toolchain.sh /tmp/ <del> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  pc # Build deprecated target 'x86_64-sun-solaris2.10' until removed RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  sun RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc sun </ins> COPY host-x86_64/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh

Related discussion:
text: removed the alias of to , but as far as I can tell did not remove the target itself. After inquiring on Zulip, it was pointed out that the target was demoted to tier three, meaning builds are no longer provided. It appears this was done with no discussion, warning, or even a mention in the release notes. Given that the target hasn't been around for that long (I think? feel free to tell me I'm wrong), I think this change should be reverted. My CI unexpectedly failed after being unable to download the target, and the only solution that wouldn't involve a notable increase in complexity of the CI script is to outright remove the checks for Solaris/Illumos — a let loss for everyone. cc
I think my feeling right now is that we should likely re-enable the sun-solaris target alongside the pc-solaris, I don't think that should be a major problem for CI times or similar. I will see if we can do this in time for 1.52.1, but if it ends up being harder than expected, I think it's likely that either a) we'll push it out to a 1.52.2 release later in the cycle, or simply leave it to 1.53. For the time being, tagging as 1.53.
I will note that the change itself is fine, of course, it's the suddenness and unexpectedness of it that caught me by surprise.
I think it is likely true that we'll eventually drop the sun target, but it does seem like we should communicate that change better at least. Certainly the newly merged target tier policy suggests just that:
It is not clear to me what the impact of was. In particular, the produced target was not changed in , but I guess the target definition is sort of for pc... I think I am not sufficiently confident in moving in a particular direction here - and a full revert does not seem quite right either - so I will likely say this should be left for at least 1.52.2 or 1.53.0. cc as well, who reviewed
Removal of the older target was certainly not my intent; if that happened due to , I am sorry. Both and are there and both targets are usable when compiling with , but I guess that change to one of files might have resulted in artifacts necessary for no longer being available.
Code change:
COPY host-x86_64/dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh COPY host-x86_64/dist-various-2/build-solaris-toolchain.sh /tmp/ <del> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  pc # Build deprecated target 'x86_64-sun-solaris2.10' until removed RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386  sun RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc sun </ins> COPY host-x86_64/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh

Related discussion:
text: I created , which I believe should bring back the ability to the old target.
Reopening to track the illumos target work. I'm not sure it's a release blocker, but would like to not lose sight.
The remaining bug in this issue -- the change in the compiler used to build illumos to be based on a -pc- triple, not -sun- here is not a release blocker.
Realistically I don't think there's anything actionable here, so I'm going to go ahead and close this.
Code change:
} } <del> fn frame_address(f: &fn(++x: *u8)) { </del> <ins> fn frame_address(f: &fn(x: *u8)) { </ins> unsafe { rusti::frame_address(f) }

Related discussion:
text: This function still takes its argument by explicit .
also,
I'm doing this, just waiting for tests.
Done, pending
Fixed in
Code change:
fn check_bounds_on_type_parameters(cx: &mut Context, e: &Expr) { let method_map = cx.tcx.method_map.borrow(); <del> let method = method_map.find(&typeck::MethodCall::expr(e.id)); </del> <ins> let method_call = typeck::MethodCall::expr(e.id); let method = method_map.find(&method_call); </ins> // Find the values that were provided (if any) let item_substs = cx.tcx.item_substs.borrow();

Related discussion:
text: Example: This should be fixed by code in .
Nominating for 1.0, P-backcompat-lang.
Assigning 1.0, P-backcompat-lang
Code change:
assert!(first.maybe_empty); first.add_all(subfirst); <del> if subfirst.maybe_empty || seq_rep.op == quoted::KleeneOp::ZeroOrMore { </del> <ins> if subfirst.maybe_empty || seq_rep.op == quoted::KleeneOp::ZeroOrMore || seq_rep.op == quoted::KleeneOp::ZeroOrOne { </ins> // continue scanning for more first // tokens, but also make sure we // restore empty-tracking state

Related discussion:
text: The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened
Code change:
<ins> pub trait Bar<S> {} pub trait Qux<T> {} pub trait Foo<T, S> { fn bar() where T: Bar<S>, { } } pub struct Concrete; impl<S> Foo<(), S> for Concrete {} impl<T, S> Bar<S> for T where S: Qux<T> {} impl<T, S> Qux<T> for S where T: Bar<S> {} </ins>

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: Rustdoc compiles the documentation as for older toolchains (stable, < nightly-2022-08-10) or as it is happening for / Instead, this happened: Rustdoc reports an compiler error <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2022-08-09 : : points to as merge that introduced this regression which is a roll-up PR. and are included there and seems to be rustdoc releated. Pinging and as authors of these PR's. <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the bug is coming from cc EDIT: also, would be quite useful to have a minimum code that we can use as a regression test.
Reducing compiler errors coming from diesel is quite hard and takes a lot of time. Diesel is already part of the rust compiler tests-suite, although in an older version. So it might be easier to just update this version to a current diesel version.
This is due to my PR. claim
is not documented inside the compiler so it wouldn't be very helpful unfortunately. Also, I didn't ask you specifically, just thought it might be useful to say it, so don't worry if you don't have time for it. :wink: Thanks !
The corresponding test code is here: I think it did not catch this issue as it uses an older diesel version (and it does not enable the corresponding feature flag).
I minimized this: And fix PR incoming.
This apparently was not fixed.
I can confirm that this is fixed for . Thank you all for the fast fix :tada:
Code change:
<ins> // revisions: current next //[next] compile-flags: -Znext-solver // check-pass #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete trait Id { type Output: ?Sized; } impl<T: ?Sized> Id for T { type Output = T; } trait Everyone {} impl<T: ?Sized> Everyone for T {} fn hello() where for<T> <T as Id>::Output: Everyone {} fn main() { hello(); } </ins>

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. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Code change:
let associated_trait = tcx.impl_trait_ref(did).map(ty::EarlyBinder::skip_binder); <ins> // Do not inline compiler-internal items unless we're a compiler-internal crate. let is_compiler_internal = |did| { tcx.lookup_stability(did) .is_some_and(|stab| stab.is_unstable() && stab.feature == sym::rustc_private) }; let document_compiler_internal = is_compiler_internal(LOCAL_CRATE.as_def_id()); let is_directly_public = |cx: &mut DocContext<'_>, did| { cx.cache.effective_visibilities.is_directly_public(tcx, did) && (document_compiler_internal || !is_compiler_internal(did)) }; </ins> // Only inline impl if the implemented trait is // reachable in rustdoc generated documentation if !did.is_local() && let Some(traitref) = associated_trait <ins> && !is_directly_public(cx, traitref.def_id) </ins> { <del> let did = traitref.def_id; if !cx.cache.effective_visibilities.is_directly_public(tcx, did) { return; } if !tcx.features().rustc_private && !cx.render_options.force_unstable_if_unmarked { if let Some(stab) = tcx.lookup_stability(did) && stab.is_unstable() && stab.feature == sym::rustc_private { return; } } </del> <ins> return; </ins> } let impl_item = match did.as_local() {

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:
<ins> // Regression test for issue #110856, where a borrowck error for a MIR tainted // all promoteds within. This in turn generated a spurious "erroneous constant // used" note when trying to evaluate a promoted. pub fn f() -> u32 { let a = 0; a = &0 * &1 * &2 * &3; //~^ ERROR: cannot assign twice to immutable variable a } fn main() {} </ins>

Related discussion:
text: I tried : I expected to see this happen: an error about not being able to move out of a slice Instead, this happened: the error and a bunch of Fails on , works fine on
It also applies to way simpler code like:
searched nightlies: from nightly-2023-04-01 to nightly-2023-04-26 regressed nightly: nightly-2023-04-22 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsHost triple: x8664-unknown-linux-gnu Reproduce with: </details Intestingly, the same day also contained two PRs but I have bisected this twice (with manual promt) and const prop lint really does seem to be the cause: commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
[[package]] name = "rustfmt-nightly" <del> version = "0.1.9" </del> <ins> version = "0.2.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "diff 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",

Related discussion:
text: First seen on as , looks like: compilefail,E0422nfn main () {n let x = Foo { x: 1, y: 2 };n}ncompilefailnfn main () {n let foo = 1;n let x = foo { x: 1, y: 2 };n}n cc
Also hit this on Travis (same test) in .
cc me
This is causing lots of CI failures. Should this test be disabled until a fix can be found?
We believe a fix is pending in , once that lands we should be good to go.
I just saw this again, reopening...
These haven't shown up in quite some time, so closing.
Code change:
all(target_vendor = "fortanix", target_env = "sgx"), feature(slice_index_methods, coerce_unsized, sgx_platform) )] <ins> #![cfg_attr(windows, feature(round_char_boundary))] </ins> // // Language features: #![feature(alloc_error_handler)]

Related discussion:
text: (and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
Code change:
all(target_vendor = "fortanix", target_env = "sgx"), feature(slice_index_methods, coerce_unsized, sgx_platform) )] <ins> #![cfg_attr(windows, feature(round_char_boundary))] </ins> // // Language features: #![feature(alloc_error_handler)]

Related discussion:
text: I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole
Code change:
<ins> #[no_mangle] pub extern "C" fn hello() { println!("Hello world!"); } #[no_mangle] pub extern "C" fn number() -> u32 { 42 } </ins>

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried to build using a simple then . I expected to see this happen: linking success. Instead, this happened: MSVC link returns LNK2005 and fails to the static library. It most recently worked on: 1.77.2 <!-- Provide the version you are using that has the regression. --: This is caused by both and When creating stdlibs, each MR causes the Rust compiler to add an export of ; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from This error will not be found until one consumes the Rust-generated library. I am filing this report to consolidate the ones in and <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged
cc
Using for a rust staticlib seems weird to me but cc
The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here:
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library.
Both: I'm using the Rust-produced static library through , plus a module definition file, to create a dynamic library. This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here:
In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue.
I am still struggling to understand why is needed, at least for MSVC.
Code change:
<ins> #[no_mangle] pub extern "C" fn hello() { println!("Hello world!"); } #[no_mangle] pub extern "C" fn number() -> u32 { 42 } </ins>

Related discussion:
text: So the DLL is created here: is used so that the DLL includes every single object in the staticlib, even if it's unneeded or indeed causes conflicts. But then is used to add a which presumably defines what actually gets exported from the DLL. What I'm not understanding is what would be different if, for MSVC, it just linked normally without ? I.e. using instead.
On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. . However, PE-COFF static libraries don't support symbol visibility, so the is there to make all Rust symbols private and keep only the librsvg ones. See e.g. and for consequences of not blocking out symbols like .
Sure but the should work regardless of if is used or not because using the export will force the linker to go looking for the symbol(s) listed in the file. E.g. as a test I have the following static lib (using to make symbols easier to find): Which I compile into a static lib using: rustc -O --crate-type=staticlib And I have the following file: Which for simplicity I compile via rustc but I'm using an empty file and also raw linker arguments: rustc -O --crate-type=cdylib -C link-args=" " This compiles and if I see the two functions I wanted: No std symbols are exported.
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault.
If I repeat the above using even in this simple case I get a bunch of errors, not just : I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC.
All duplicate symbol errors for are caused by That it works without is by accident and likely to break in case of cgu partitioning changes.
Code change:
<ins> #[no_mangle] pub extern "C" fn hello() { println!("Hello world!"); } #[no_mangle] pub extern "C" fn number() -> u32 { 42 } </ins>

Related discussion:
text: Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.
Code change:
// ignore-tidy-linelength // ignore-lldb <del> // ignore-android: FIXME(#10381) </del> <ins> // ignore-android: FIXME(#24958) </ins> // compile-flags:-g

Related discussion:
text: Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Code change:
"codegen-units"); suite("check-incremental", "src/test/incremental", "incremental", "incremental"); <del> suite("check-ui", "src/test/ui", "ui", "ui"); </del> } if build.config.build.contains("msvc") {

Related discussion:
text: Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output: