jiebi/CodeConvo huggingface dataset:
Change:
<ins> use super::utf16_to_utf8; #[test] fn zero_size_read() { assert_eq!(utf16_to_utf8(&[], &mut []).unwrap(), 0); } </ins>

Discussion:
<!-- 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: In windows terminal running Git Bash (also occured in Nushell, though I'm not sure if this is terminal or shell-land), I pressed Ctrl-Z + Enter to send EOF. I expected to see this happen: The application would gracefully exit the loop Instead, this happened: I saw this error message: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
The underlying regression here is that the way we call does not accept zero length strings. And we're calling in a way that makes ctrl-z immediately return without reading anything after it. This is important because a zero length read is how we signal to stdlib that an eof has occurred (so ctrl-z handling is pretty indirect). The fix is simple, if anyone wants to claim this issue. needs to check for zero length input and immediately return in that case.
Seems like a good first issue, I can take a stab at it.
That would be great!
Where would be a good place to write a test for this?
Hm, this is a Windows specific issue so it should probably stay close to the affected code. Take a look at how for tests and do something similar for stdio.
Never mind, I see how things are glued together.
It's a sub module so it should be able to access the private functions of its parent (aka ) module. This is noted in the :
For sure, just misread the directory structure.
Change:
if let Some((did, ty)) = decl.output.as_return().and_then(|t| Some((t.def_id(cx.cache())?, t))) { <ins> // Box has pass-through impls for Read, Write, Iterator, and Future when the // boxed type implements one of those. We don't want to treat every Box return // as being notably an Iterator (etc), though, so we exempt it. Pin has the same // issue, with a pass-through impl for Future. if Some(did) == cx.tcx().lang_items().owned_box() || Some(did) == cx.tcx().lang_items().pin_type() { return "".to_string(); } </ins> if let Some(impls) = cx.cache().impls.get(&did) { for i in impls { let impl_ = i.inner_impl();

Discussion:
The and documentation shows "notable traits" on the method, and any other methods that return a Pin or a Box: ! That's because these structs have "pass-through" implementations: if implements , then implements . If implements , then implements . Since returns , it gets the icon indicating a notable trait. These return types should not be annotated with the , since "notable traits" should be reserved for things that are actually notable - like the impl on . One way to achieve this: if the bounds for the impl include the "notable trait", don't consider that impl eligible for treatment.
Out of curiosity, I a to emit a list of which types get the "notable traits" annotation for which traits. Running this over std, emitting one line per instance, and going through , I get the below. For instance, shows up as a return type 183 times in the std docs, with a "notable trait" of iterator each time. The high count for iterator types is expected - it's because these get repeated on different pages for every item that implements Iterator. After the iterator types, slice's Read/Write impls and Box's Read/Write/Future/Iterator impls are the most frequent.
I got a PR implementing this solution, just need to clean it up. What's the best way to make a test for this? Just a regular rustdoc test?
Yep! Specifically one of the tests under src/test/rustdoc that generates documentation for a small example and then makes assertions on the output. Note that this is a bit of a tricky test since it's a negative assertion. So it would be easy for the test to pass but for unrelated reasons (for instance if we changed the HTML layout). To avoid that problem I recommend having two parts of the test, for two different items: one item that should have the annotation, and one item that should not have the annotation. That way if the HTML layout changes the test will fail.
any updates? BTW I think it would be reasonable to just special case "Box" and "Pin" by name and say they should never get the treatment.
Sorry, gotta rebase this, and I saw some weird regressions in the UI tests with this heuristic...
Ugh, sorry, probably won't get around to fixing this. I'll unclaim.
Change:
<ins> error[E0596]: cannot borrow `*v` as mutable, as it is behind a `&` reference --> $DIR/issue-82032.rs:10:13 | LL |         for v in self.0.values() { |                  --------------- |                  |      | |                  |      help: use mutable method: `values_mut()` |                  this iterator yields `&` references LL |             v.flush(); |             ^ `v` is a `&` reference, so the data it refers to cannot be borrowed as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Discussion:
<!-- 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. --<!-- 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. --: The internal compiler error does not occur in stable (): The fix for compilation is to use instead of and this also prevents the panic in the nightly version of rustc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
It would be nice to reproduce this without the async-std dependency.
Slightly smaller:
I bisected far enough to find it regressed between the 9th and 10th, then ran out of disk space :facepalm:
Smaller example without
Here you go. The async part doesn't seem important and the issue still occurs with the versions of and and removed from dependencies: It could probably be reduced in size further but I'm not much of a Rust expert. I suspect anything which triggers that particular compiler error would do the trick.
searched nightlies: from nightly-2021-02-10 to nightly-2021-02-11 regressed nightly: nightly-2021-02-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Probably cc In particular looks suspect.
Are functions registered as items in the hir? edit: nvm just saw that someone posted a non-async example
Change:
/// assert_eq!(squared, Poll::Ready(Some(Ok(144)))); /// ``` #[stable(feature = "poll_map", since = "1.51.0")] <ins> #[inline] </ins> pub fn map_ok<U, F>(self, f: F) -> Poll<Option<Result<U, E>>> where F: FnOnce(T) -> U,

Discussion:
I noticed that in one of my project, inlining [] manually reduces some binary size, then I noticed is not marked . Since both [] and [] are marked , I wonder whether this is an oversight. I failed to reproduce the binary size reduction effect with an example code, but maybe the reason behind inlining and also applies to ? How about [] and []? []: []: []: []: []:
That's surprising. Can you share your project?
Unfortunately, it is a private project, I cannot share it.
Ah okay. I find it suspicious that these functions aren't inlining already. Did you try building your project against a modified standard library with to those functions? Do you still get a code size improvement from manual inlining if you compile with and/or in your release profile? The functions in question ought to already be eligible for inlining, but by default the release profile has multiple codegen units per crate, which can result in surprising failures to inline things. How big are these functions once they are compiled in your crate? The third-party tool can help out here, can you share the output of (of course trimming that down a bit if there are type names in there you don't want to fully disclose) If for whatever reason these functions end up looking big to LLVM after other things are inlined into them, that may explain what's going on here, and your manual inlining has effectively changed in what order LLVM considers inlining things.
I have done some tests on my project, using to check for symbols: Using , does not get inlined; Using , gets inlined; Using and , add to standard library source code, gets inlined; All configurations above are using and . reports that each is about 68 to 96 bytes.
What about and to the standard library code, but without using ? If that configuration gets these functions inlined I think this is worth doing because it unlocks additional useful optimizations for users, but if the optimization is gated behind it's a bit less certain if this is a win. Do you or any other LLVM folks have insight into why would be impactful here? Are we relying on the hint part of its behavior?
It seems that changing standard library source code only works with . Do I need to compile a customized version of Rust in order to test it?
That's what I do. It's a very slow workflow.
Change:
} } <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> unsafe impl<'a, I, T: 'a> TrustedLen for Copied<I> where I: TrustedLen<Item=&'a T>, T: Copy

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
// Finally, resolve all regions. let outlives_env = OutlivesEnvironment::new(param_env); <del> infcx.resolve_regions_and_report_errors(impl_did, &outlives_env); </del> <ins> infcx.check_region_obligations_and_report_errors(impl_did, &outlives_env); </ins> } } _ => {

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
<del> An inherent implementation was defined for something which isn't a struct nor an enum. </del> <ins> An inherent implementation was defined for something which isn't a struct, enum, union, or trait object. </ins> Erroneous code example: ```compile_fail,E0118 <del> impl (u8, u8) { // error: no base type found for inherent implementation </del> <ins> impl (u8, u8) { // error: no nominal type found for inherent implementation </ins> fn get_state(&self) -> String { // ... }

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
<ins> extern crate lib; use lib::trampolines::*; fn main() { unsafe { table_fill_externref(); table_fill_funcref(); } } </ins>

Discussion:
This will take quite a while; sorry, I don't have a more minimal reproduction on hand since the issue doesn't reproduce on a toy example and reducing the actual reproduction into a minimal example is tricky when it takes forever to reproduce. The compilation succeeds. Linking fails. rustc 1.69.0-nightly ( 2023-01-23) rustc 1.69.0-nightly ( 2023-02-13) Linux+amd64 The issue also reproduces on macOS+aarch64. I'm not sure whether this is a generic LTO bug, or a bug with . The  crate sets up a bunch of trampolines like this: <details<summaryRelevant code</summary</detailsSo as you can see the symbol that's being unnecessarily stripped out is being passed into the block () and that is being called from assembly (). That symbol is just a normal mangled extern "C" function (). What's also interesting is also that this seems to affect only these two symbols (there are more that are defined, and it seems like those are not being stripped out for some reason), and that it doesn't reproduce on toy examples. There are also two potential workarounds; first workaround is to just mark the function as : The other is to create a dummy variable with a on it: After applying either of those the linking succeeds even when LTO is enabled. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might or might not be related:
This is a minimal reproduction that works on macOS and Linux (x86_64). I think the fixes this issue.
label +A-llvm
claim
Change:
self.err_dotdotdot_syntax(self.token.span); } <ins> if self.token == token::LArrow { self.err_larrow_operator(self.token.span); } </ins> self.bump(); if op.is_comparison() { self.check_no_chained_comparison(&lhs, &op);

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
<ins> #[derive(Clone, Debug)] // OK struct S; #[derive(Debug, inline)] //~ ERROR expected derive macro, found built-in attribute `inline` struct T; #[derive(inline, Debug)] //~ ERROR expected derive macro, found built-in attribute `inline` struct U; fn main() {} </ins>

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
// FIXME: work properly with higher limits <ins> #[cfg(target_word_size = "32")] </ins> fn main() { let big: Option<[u32, ..(1<<29)-1]> = None; } <ins> #[cfg(target_word_size = "64")] fn main() { let big: Option<[u32, ..(1<<45)-1]> = None; } </ins>

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.
Change:
sized_args = [v0]; &sized_args } else { <ins> // FIXME(#36457) -- we should pass unsized values to drop glue as two arguments </ins> unsized_args = [ Load(bcx, get_dataptr(bcx, v0)), Load(bcx, get_meta(bcx, v0))

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
/// // Now `as_slice` returns "[2, 3]": /// assert_eq!(iter.as_slice(), &[2, 3]); /// ``` <del> #[unstable(feature = "slice_iter_mut_as_slice", reason = "recently added", issue = "58957")] </del> <ins> #[stable(feature = "slice_iter_mut_as_slice", since = "1.53.0")] </ins> pub fn as_slice(&self) -> &[T] { self.make_slice() } } <ins> #[stable(feature = "slice_iter_mut_as_slice", since = "1.53.0")] impl<T> AsRef<[T]> for IterMut<'_, T> { fn as_ref(&self) -> &[T] { self.as_slice() } } </ins> iterator! {struct IterMut -> *mut T, &'a mut T, mut, {mut}, {}} /// An internal abstraction over the splitting iterators, so that

Discussion:
This issue tracks stabilization for 2 methods in : -
If this feature is accepted, they should implement as well.
Good point, I didn't notice that already implements . Another candidate that could is , and maybe there are more to consider for completeness.
I actually didn't notice either until I went digging in for a totally separate issue. Will have a PR for that separately, although I won't include because it'd be instantly stable, and I'm not sure whether we want to guarantee that.
Is there a reason to not add asslicemut for these? Particularly IterMut, where it makes the iteration over mutable pairs nicer.
Only is sound, and that's offered at the moment. Otherwise, you can have multiple mutable borrows to the same spot in memory.
should be just as sound as here. It could not be , but that's true for & as well.
Yes, as long as it borrows from the itself, not its parameterized lifetime, should be fine. I guess for mutable pairs, you mean something like this?
Yeah, exactly that.
What is the status of this? Is anything required for stabilization other than someone to propose stabilization, make a stabilization PR, and FCP? In rowan, rust-analyzer's syntax tree backend, to remove unneeded allocations from syntax node cache hits. A simple patch that just does so via an arrayvec already sees a 5% improvement on rust-analyzer's main integration benchmark (not rowan's, and not purely parsing!), but being able to use the fact that already has a non-destructively-iterable array backing would make even that collect/copy unnecessary.
One of thse (vec::Drain::as_slice) is already stabilized. As for the other one: we discussed this tracking issue in the libs meeting, and would be happy to see a stabilization PR.
Change:
} #[stable(feature = "std_debug", since = "1.16.0")] <del> impl<'a, K: Debug, V: Debug> fmt::Debug for Values<'a, K, V> { </del> <ins> impl<'a, K, V: Debug> fmt::Debug for Values<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list() .entries(self.clone())

Discussion:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.
Change:
As an example, here is a program that will calculate the dot product of two vectors provided from C, using idiomatic Rust practices. <del> ``` </del> <ins> ```ignore </ins> #![feature(lang_items, start, no_std, core, libc)] #![no_std]

Discussion:
I have noted a regression in starting from (found with bisect). the failing test is one of . The fail occurs with stage1 and with stage2 (it have help a lot for bisect: only 50 min for 1 step of bisect) I extract the example to a standalone file, and manually run rustc: the error is a linking error: it seems -lgcc isn't passed by rustc, whereas the symbol was present in . Any help would be appreciate.
I have the same issue. It worked fine in nightly (2015-03-28), but now in nightly (2015-04-13) I get these errors when trying to link my standalone kernel with libcore: It only happens when I use my custom : If I try to add manually: ...Rust gives me this error instead: Is there a solution or workaround? <br /
you could try to explicitly link with libgcc by providing on rustc command-line.
Can that be done through Cargo too? As I've only used Cargo up to now.
I really don't known... (I don't have cargo on openbsd). You could try to add in your file.