jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] pub extern crate core; </ins>

Related discussion:
text: On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] pub extern crate core; </ins>

Related discussion:
text: In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .
Code change:
///   as the compiler doesn't need to prove that it's sound to elide the ///   copy. /// <ins> /// Unaligned values cannot be dropped in place, they must be copied to an aligned /// location first using [`ptr::read_unaligned`]. /// </ins> /// [`ptr::read`]: ../ptr/fn.read.html <ins> /// [`ptr::read_unaligned`]: ../ptr/fn.read_unaligned.html </ins> /// /// # Safety ///

Related discussion:
text: The docs for  state: And include an example which uses to copy the value from an unaligned pointer into an aligned one. However, the docs for  state: Either the docs for are wrong, and does not need to be aligned, or the example for invokes UB and should be updated to use
cc (It's also notable that the example in is wrong when it uses as is seen if you move the statement out of the block; we should fix that ASAP)
Good catch! What we'd really want is , I think... we don't want an intermediate value on the stack. Feel free to suggest code that we can use instead. We have several doctests that need They have been there since 1.0 and longer, probably. But nobody listens to me when I say that there is existing code that we need to support ASAP.
The example given is just using to put it on the stack anyway. If you're having to copy the value at all, there's really no reason to use at that point, since the only reason to use it instead of is to avoid the copy (which is optimized out in release mode anyway). I think we can probably just remove the unaligned example entirely and change the documentation to read: I think we should probably mention the caveat WRT the optimizer eliminating the copy (or can it even do that in this case? The docs mention that the drop glue generated for packed structs does this copy automatically, I'm curious if it's doing so in a way that is UB or if the copy is just the price you have to pay here. It's also worth noting that there's no way to an unsized value through an unaligned pointer, but I'm not sure that's worth bringing up at all in the docs, since there's no reasonable way to actually get that pointer in the first place.
Oh, good point. Yeah then you can basically just make it , right? I wonder why / ever got used here? Well but wouldn't it make sense for that text to come with an example? It cannot, because then it would be introducing alignment errors. Uh... yeah. With it could work. Doesn't seem like a reasonable thing to have either way?
Presumably because they wanted the example to continue to use Sure, we could -- it just wouldn't ever call the function being documented.
Code change:
///   as the compiler doesn't need to prove that it's sound to elide the ///   copy. /// <ins> /// Unaligned values cannot be dropped in place, they must be copied to an aligned /// location first using [`ptr::read_unaligned`]. /// </ins> /// [`ptr::read`]: ../ptr/fn.read.html <ins> /// [`ptr::read_unaligned`]: ../ptr/fn.read_unaligned.html </ins> /// /// # Safety ///

Related discussion:
text: Yes, it's just unrelated to dropping unaligned pointers since the only place you can reasonably copy them to is the stack. Unless you happen to already have an valid pointer of the proper size and alignment sitting around
I'm not actually sure unalgined DSTs are so unreasonable. For example, is only stopped by this rule: Which could be solved if we had e.g. a way to express "does not have drop glue" as a bound ( doesn't work for obvious reasons). In any case, I think "copy unaligned" functions make sense but we might want to consider multiple variants for src only / dest only / both unaligned. This can be expressed in LLVM IR though in a brief test I couldn't demonstrate that it currently makes a codegen difference (but I could only try on x86_64, where alignment rarely matters for codegen).
:rofl: fair. I guess all of this is basically saying an in-place drop of unaligned data is just not possible. Do an "out-of-place" drop instead.
Actually looks like the use of an unaligned pointer in the doctest just caused to fail to land. ;)
Proposed fix at
Code change:
pub const FILE_TYPE_PIPE: u32 = 3; <ins> pub const CP_UTF8: DWORD = 65001; pub const MB_ERR_INVALID_CHARS: DWORD = 0x08; pub const WC_ERR_INVALID_CHARS: DWORD = 0x80; </ins> #[repr(C)] #[derive(Copy)] pub struct WIN32_FIND_DATAW {

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:
pub const FILE_TYPE_PIPE: u32 = 3; <ins> pub const CP_UTF8: DWORD = 65001; pub const MB_ERR_INVALID_CHARS: DWORD = 0x08; pub const WC_ERR_INVALID_CHARS: DWORD = 0x80; </ins> #[repr(C)] #[derive(Copy)] pub struct WIN32_FIND_DATAW {

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:
// inferred in this method call. let arg = &args[i]; let arg_ty = self.node_ty(arg.hir_id); <del> err.span_label( arg.span, &format!( "this is of type `{arg_ty}`, which causes `{ident}` to be  inferred as `{ty}`", ), ); </del> <ins> if !arg.span.overlaps(mismatch_span) { err.span_label( arg.span, &format!( "this is of type `{arg_ty}`, which causes `{ident}` to be  inferred as `{ty}`", ), ); } </ins> param_args.insert(param_ty, (arg, arg_ty)); } }

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
} } <ins> fn handle_assign(&mut self, expr: &'tcx hir::Expr<'tcx>) { if self .typeck_results() .expr_adjustments(expr) .iter() .any(|adj| matches!(adj.kind, ty::adjustment::Adjust::Deref(_))) { self.visit_expr(expr); } else if let hir::ExprKind::Field(base, ..) = expr.kind { // Ignore write to field self.handle_assign(base); } else { self.visit_expr(expr); } } </ins> fn handle_field_pattern_match( &mut self, lhs: &hir::Pat<'_>,

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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.
Code change:
rbml_w.wr_tagged_str(tag_crate_hash, hash.as_str()); } <ins> fn encode_rustc_version(rbml_w: &mut Encoder) { rbml_w.wr_tagged_str(tag_rustc_version, &rustc_version()); } </ins> fn encode_crate_name(rbml_w: &mut Encoder, crate_name: &str) { rbml_w.wr_tagged_str(tag_crate_crate_name, crate_name); }

Related discussion:
text: When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata
Code change:
<ins> #![deny(warnings)] //! Email me at <hello@localhost>. //~^ ERROR unknown disambiguator `hello` //! This should *not* warn: <hello@example.com>. </ins>

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. --I tried this code: I expected to see this happen: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- 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. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.
Code change:
<ins> #![deny(warnings)] //! Email me at <hello@localhost>. //~^ ERROR unknown disambiguator `hello` //! This should *not* warn: <hello@example.com>. </ins>

Related discussion:
text: Hmm, that seems useful, although I think it should be a separate issue. Maybe we could try resolving without a disambiguator and see if there are any results? That would need a pretty significant overhaul of how it works currently, right now all the errors are emitted eagerly which would end up with a lot more verbose output that might not be relevant. What would you expect to see if the link isn't valid even without the disambiguator?
I think an extra to more docs on intradoc link disambiguators would be helpful per your previous comment. The idea to attempt to resolve items for all invalid disambiguators feels similar to the Ruby CLI and REPL's "did you mean" feature, which I find quite useful.
The PR improving the diagnostics is being reverted in , reopening the issue.
I don't think this is still a regression; the diagnostics improvement was not part of the fix for the regression. (The regression was fixed in .)
Yeah, never had a tracking issue.
was relanded in
Code change:
<ins> // This used to cause an ICE for an internal index out of range due to simd_shuffle_indices being // passed the wrong Instance, causing issues with inlining. See #67557. // // run-pass // compile-flags: -Zmir-opt-level=3 #![feature(platform_intrinsics, repr_simd)] extern "platform-intrinsic" { fn simd_shuffle2<T, U>(x: T, y: T, idx: [u32; 2]) -> U; } #[repr(simd)] #[derive(Debug, PartialEq)] struct Simd2(u8, u8); fn main() { unsafe { let _: Simd2 = inline_me(); } } #[inline(always)] unsafe fn inline_me() -> Simd2 { simd_shuffle2(Simd2(10, 11), Simd2(12, 13), [0, 3]) } </ins>

Related discussion:
text: It should use . ( is the second field of .) While both instances are normally equal, they can differ after running the mir inliner. In that case the promoted will refer to the inlined function. modify labels: +A-mir +C-bug +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Can I give this a go? claim
Do you have any specific tests in mind I should add to check for the correct behaviour?
should be a test if the mir inliner would to inline . Somehow it doesn't though.
You might be running into this unfortunate check Try moving below .
Wow, that's hilarious. With just the changes suggested, the inlining still doesn't work properly, but doesn't seem to break any existing stuff. But I've just tried this and yeah, putting ret_slice below main has made the MIR inliner work.
This does inline, but somehow no assertion fires with current rustc. The printed MIR doesn't seem to show the the def_id from which the promoted originates, so I don't know what the problem is.
Unless I'm misunderstanding something, isn't this the correct behaviour? Both of those assertions are true, and swapping and around in the assertions correctly triggers an assertion failure.
I forgot that this problem was only with .
I got a working test:
Ah, that's a good test case. Yeah, that's definitely not the expected behaviour. While messing about with your example, I also managed to come across an ICE with this slightly shorter version: causes an ICE currently due to an internal index out of range. The good news is that the changes you suggested fixes both of these test cases. Good spot :) I'm putting up the PR now.
Code change:
#[derive(Copy, Clone)] pub struct Quad { a: u64, b: u64, c: u64, d: u64 } <ins> #[derive(Copy, Clone)] pub struct QuadFloats { a: f32, b: f32, c: f32, d: f32 } </ins> #[repr(C)] #[derive(Copy, Clone)] pub struct Floats { a: f64, b: u8, c: f64 }

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:
#[derive(Copy, Clone)] pub struct Quad { a: u64, b: u64, c: u64, d: u64 } <ins> #[derive(Copy, Clone)] pub struct QuadFloats { a: f32, b: f32, c: f32, d: f32 } </ins> #[repr(C)] #[derive(Copy, Clone)] pub struct Floats { a: f64, b: u8, c: f64 }

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