jiebi/CodeConvo huggingface dataset:
Change:
}) } <del> /// Use the `format!` syntax to write data into a buffer. </del> <ins> /// Write formatted data into a buffer </ins> /// <del> /// This macro is typically used with a buffer of `&mut `[`Write`][write]. </del> <ins> /// This macro accepts any value with `write_fmt` method as a writer, a format string, and a list /// of arguments to format. /// /// `write_fmt` method usually comes from an implementation of [`std::fmt::Write`][fmt_write] or /// [`std::io::Write`][io_write] traits. These are sometimes called 'writers'. /// /// Passed arguments will be formatted according to the specified format string and the resulting /// string will be passed to the writer. </ins> /// /// See [`std::fmt`][fmt] for more information on format syntax. /// <ins> /// Return value is completely dependent on the 'write_fmt' method. /// /// Common return values are: [`Result`][enum_result], [`io::Result`][type_result] /// </ins> /// [fmt]: ../std/fmt/index.html <del> /// [write]: ../std/io/trait.Write.html </del> <ins> /// [fmt_write]: ../std/fmt/trait.Write.html /// [io_write]: ../std/io/trait.Write.html /// [enum_result]: ../std/result/enum.Result.html /// [type_result]: ../std/io/type.Result.html </ins> /// /// # Examples ///

Discussion:
Looking at  documentation page, the only thing you can figure out is that does return something and “something” has a method.
I'm pretty sure that write is not even guaranteed to return anything with an method... Write basically calls whatever method on is in scope (and makes no_ other guarantees).
It, then, should document that.
Yay duck typing!
part of
I would be willing to work with anyone who wanted to fix this issue.
Some related issues regarding that macro & it's documentation: ,
Hello! I can work on this.
great! Do you need any help from me?
Hello. Not currently. I'll come up with a PR and ask your comments on it tomorrow or the next day. Thanks for keeping an eye!
Change:
/// assert_eq!(poll_some_len, Poll::Ready(13)); /// ``` #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[inline] </ins> pub fn map<U, F>(self, f: F) -> Poll<U> 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:
pub fn ReleaseSRWLockShared(SRWLock: PSRWLOCK); pub fn TryAcquireSRWLockExclusive(SRWLock: PSRWLOCK) -> BOOLEAN; pub fn TryAcquireSRWLockShared(SRWLock: PSRWLOCK) -> BOOLEAN; <ins> pub fn CompareStringOrdinal( lpString1: LPCWSTR, cchCount1: c_int, lpString2: LPCWSTR, cchCount2: c_int, bIgnoreCase: BOOL, ) -> c_int; </ins> } // Functions that aren't available on every version of Windows that we support,

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: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- 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. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.
Change:
// the AST for typechecking. err.span_label(ident.span, "while parsing this `fn`"); err.emit(); <del> (Vec::new(), None) </del> } else { return Err(err); } <del> } else { unreachable!() </del> } <ins> (Vec::new(), None) </ins> }; attrs.extend(inner_attrs); Ok(body)

Discussion:
Playground with repro . Not present in latest stable or beta. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regressed since , I think is the cause.
right, this issue can be probably be closed as duplicate of
I would suggest not closing this issue as long as literally starts with the statement referencing back to this issue. Furthermore, this issue is older, so if they’d be duplicates, would be closed.
Change:
//! Context itself, span_lint should be used instead of add_lint. use driver::session; <ins> use middle::dead::DEAD_CODE_LINT_STR; </ins> use middle::privacy; use middle::trans::adt; // for `adt::is_ffi_safe` use middle::ty;

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
StorageLive(_20); _20 = (); _0 = Poll::<()>::Pending; <ins> StorageDead(_3); StorageDead(_4); StorageDead(_19); StorageDead(_20); </ins> discriminant((*(_1.0: &mut {async fn body@$DIR/async_await.rs:15:18: 18:2}))) = 3; return; }

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
Change:
if OPTIONS.iter().any(|&opt| s == opt) { cx.span_warn(p.last_span, "expected a clobber, found an option"); <ins> } else if s.starts_with("{") || s.ends_with("}") { cx.span_err(p.last_span, "clobber should not be surrounded by braces"); </ins> } clobs.push(s); } }

Discussion:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.
Change:
/// assert_eq!(s.find("Léopard"), Some(13)); /// ``` /// <del> /// More complex patterns with closures: </del> <ins> /// More complex patterns using point-free style and closures: </ins> /// /// ``` /// let s = "Löwe 老虎 Léopard"; /// /// assert_eq!(s.find(char::is_whitespace), Some(5)); /// assert_eq!(s.find(char::is_lowercase), Some(1)); <ins> /// assert_eq!(s.find(|c: char| c.is_whitespace() || c.is_lowercase()), Some(1)); /// assert_eq!(s.find(|c: char| (c < 'o') && (c > 'a')), Some(4)); </ins> /// ``` /// /// Not finding the pattern:

Discussion:
... but it uses point-free style, not closures. We should probably show both.
I'd like to take care of this one
that'd be great! Do you know what needs to be done, or do you need some help/advice?
If I understand, you want to change by , right?
It would be nice to have both so people still know they can use UFCS syntax (as long as it takes a char and returns a boolean) which is cleaner in trivial cases. Perhaps add an example that looks for a delimiter symbol ()
I'd say "add" rather than change, it's nice to show both. just so you know, it's not UFCS anymore, but .
TIL; Thank you steve!
Change:
<del> error: encountered dangling pointer in final value of constant </del> <ins> error[E0080]: it is undefined behavior to use this value </ins> --> $DIR/dangling-alloc-id-ice.rs:12:1 | LL | const FOO: &() = { <del> | ^^^^^^^^^^^^^^ </del> <ins> | ^^^^^^^^^^^^^^ constructing invalid value: encountered a dangling reference (use-after-free) | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. = note: the raw bytes of the constant (size: $SIZE, align: $ALIGN) { HEX_DUMP } </ins> error: aborting due to 1 previous error <ins> For more information about this error, try `rustc --explain E0080`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D
Change:
trait_missing_method: bool, ) { let mut alt_rcvr_sugg = false; <ins> let mut trait_in_other_version_found = false; </ins> if let (SelfSource::MethodCall(rcvr), false) = (source, unsatisfied_bounds) { debug!( "suggest_traits_to_import: span={:?}, item_name={:?}, rcvr_ty={:?}, rcvr={:?}",

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- 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

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
} // @has 'foo/enum.Foo.html' <del> // @has - '//h3[@class="sidebar-title"]' 'Associated Constants' // @has - '//div[@class="sidebar-elems"]//a' 'FOO' </del> <ins> // @!has - '//h3[@class="sidebar-title"]' 'Associated Constants' // @!has - '//div[@class="sidebar-elems"]//a' 'FOO' </ins> impl Trait for Foo { const FOO: u32 = 1; fn foo() {} } <ins> pub struct Baz; // @has 'foo/struct.Baz.html' // @has - '//h3[@class="sidebar-title"]' 'Associated Constants' // @has - '//div[@class="sidebar-elems"]//a' 'FOO' impl Baz { pub const FOO: u32 = 42; } pub enum Quux { B, } // @has 'foo/enum.Quux.html' // @has - '//h3[@class="sidebar-title"]' 'Associated Constants' // @has - '//div[@class="sidebar-elems"]//a' 'FOO' impl Quux { pub const FOO: u32 = 42; } </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: I expected to see this happen: I would expect not to appear as its own item in the rustdoc sidebar for the struct. This would be consistent with the behavior of methods and associated types from trait impls, which also don't appear as their own item in the sidebar. Instead, this happened: The constant is listed under "Associated Constants" in the left-hand sidebar of the rustdoc page for . This is inconsistent with how methods from trait impls appear in documentation. ! <!-- 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 was intentionally in .
The inclusion of associated consts from inherent impls is intentional. But is it intentional that associated consts from trait impls also appear in the sidebar (even though methods from trait impls do not)? (I'm filing this bug because for a crate I'm developing, the current behavior makes the sidebar extremely messy. Restricting the list of associated constants to those from inherent impls would make navigating the documentation for my crate much more pleasant.)
I think the behavior proposes makes sense.
Change:
/// Format the program and arguments of a Command for display. Any /// non-utf8 data is lossily converted using the utf8 replacement /// character. <ins> /// /// The default format approximates a shell invocation of the program along with its /// arguments. It does not include most of the other command properties. The output is not guaranteed to work /// (e.g. due to lack of shell-escaping or differences in path resolution) /// On some platforms you can use [the alternate syntax] to show more fields. /// /// Note that the debug implementation is platform-specific. /// /// [the alternate syntax]: fmt#sign0 </ins> fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { self.inner.fmt(f) }

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
pub promoted: Option<mir::Promoted>, } <ins> impl GlobalId<'tcx> { pub fn display(self, tcx: TyCtxt<'tcx>) -> String { let instance_name = tcx.def_path_str(self.instance.def.def_id()); if let Some(promoted) = self.promoted { format!("{}::{:?}", instance_name, promoted) } else { instance_name } } } </ins> /// Input argument for `tcx.lit_to_const`. #[derive(Copy, Clone, Debug, Eq, PartialEq, Hash, HashStable)] pub struct LitToConstInput<'tcx> {

Discussion:
Evaluating of promoteds currently looks very confusing in the query stack: is not a const, so "const-evaluating " is just nonsense. I presume that this is easy to fix but only would know how. ;) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also see
Let's give a try :wink:
claim
awesome. :) Let us know if you need any help. I am not very familiar with that specific code, but can still help with more general questions, and I hope can help with the specifics. :D
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(generators, generator_trait, box_leak, rustc_attrs)] </del> <ins> #![feature(generators, generator_trait, box_leak)] </ins> use std::cell::RefCell; use std::ops::Generator; <del> fn main() { #![rustc_error] // rust-lang/rust#49855 </del> <ins> fn main() { </ins> let (cell, mut gen); cell = Box::new(RefCell::new(0)); let ref_ = Box::leak(Box::new(Some(cell.borrow_mut()))); <ins> //~^ ERROR `*cell` does not live long enough [E0597] </ins> // the upvar is the non-dropck `&mut Option<Ref<'a, i32>>`. gen = || { // but the generator can use it to drop a `Ref<'a, i32>`.

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
print("ignoring already-download file", path, "due to failed verification") os.unlink(path) <del> download(temp_path, "{}/{}".format(base, url), True, verbose, help_on_error=help_on_error) </del> <ins> download(temp_path, "{}/{}".format(base, url), True, verbose) </ins> if do_verify and not verify(temp_path, sha256, verbose): raise RuntimeError("failed verification") if verbose:

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> error[E0271]: type mismatch resolving `<T as TraitWAssocConst>::A == 1` --> $DIR/const-projection-err.rs:14:11 | LL |     foo::<T>(); |           ^ expected `1`, found `<T as TraitWAssocConst>::A` | = note: expected constant `1` found constant `<T as TraitWAssocConst>::A` note: required by a bound in `foo` --> $DIR/const-projection-err.rs:11:28 | LL | fn foo<T: TraitWAssocConst<A = 1>>() {} |                            ^^^^^ required by this bound in `foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (