jiebi/CodeConvo huggingface dataset:
Change:
impl From<u8> for ExitCode { fn from(code: u8) -> Self { <del> match code { 0 => Self::SUCCESS, 1..=255 => Self::FAILURE, } </del> <ins> Self(code) </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. --When compiled as a standard binary on the host system, the exit codes are returned as expected. When compiled with wasm32-wasip1, the use of ExitCode results in the exit code of 1, regardless of the value provided to ExitCode::from. The following are the minimal examples used while reproducing the bug: The above example produces the expected error code of 10 when compiling for the the host system and (executed with wasmtime 24.0.0). The above example produces the exit code when compiled for the host system but returns exit code 1 when compiled with (again run in wasmtime 24.0.0). Looking at the resulting WASM (decompiled to WAT) we see the main function returns a (here compiled with ): For source code of the reproducer, see: Tested against stable, beta and nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
It seems that we just call ?
Minimized: claim label -O-wasi
Oh, "cool"!
that is so concise! Thanks. I’d also be very interested in getting some insight on where to look in the code base for this sort of thing.
I'm kinda just abusing my IDE (RustRover)’s Go To Declaration & Find Usages shortcuts, you may need to tell yours to use the wasm target for name resolution/code indexing instead of your OS’ default one.
I ran the tests in my reproducer repo against the latest nightly (post merge of ) and the all pass now. Thanks!
Change:
Individual targets will support different features; this flag lets you control enabling or disabling a feature. Each feature should be prefixed with a `+` to <del> enable it or `-` to disable it. Separate multiple features with commas. </del> <ins> enable it or `-` to disable it. Features from multiple `-C target-feature` options are combined.  Multiple features can be specified in a single option by separating them with commas - `-C target-feature=+x,-y`.  If some feature is specified more than once with both `+` and `-`, then values passed later override values passed earlier.  For example, `-C target-feature=+x,-y,+z -Ctarget-feature=-x,+y` is equivalent to `-C target-feature=-x,+y,+z`. </ins> To see the valid options and an example of use, run `rustc --print target-features`.

Discussion:
I'm trying to pass multiple conditionally downstream. However, despite +/- for adding/removing a feature it appears only the last value takes effect.
FWIW, you can check for values without any test program like: $ rustc --print cfg -C target-feature=+avx2 -C target-feature=+fma $ rustc --print cfg -C target-feature=+avx2,+fma
I agree that it's a bug and will try to fix it.
Fixed in
Change:
<del> error[E0597]: `a` does not live long enough --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:49 </del> <ins> error[E0373]: closure may outlive the current function, but it borrows `a`, which is owned by the current function --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:44 </ins> | LL |     [0].iter().flat_map(|a| [0].iter().map(|_| &a)); <del> |                                             -   ^- ...but `a` will be dropped here, when the enclosing closure returns |                                             |   | |                                             |   `a` would have to be valid for `'_`... |                                             has type `&i32` </del> <ins> |                                            ^^^  - `a` is borrowed here |                                            | |                                            may outlive borrowed value `a` </ins> | <del> = note: functions cannot return a borrow to data owned within the function's scope, functions can only return borrows to data passed as arguments = note: to learn more, visit <https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#dangling-references> </del> <ins> note: closure is returned here --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:29 | LL |     [0].iter().flat_map(|a| [0].iter().map(|_| &a)); |                             ^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables), use the `move` keyword | LL |     [0].iter().flat_map(|a| [0].iter().map(move |_| &a)); |                                            ^^^^^^^^ </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0597`. </del> <ins> For more information about this error, try `rustc --explain E0373`. </ins>

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
} let sub_span = self.span <del> .sub_span_of_token(path.span, token::BinOp(token::Star)); if !self.span.filter_generated(sub_span, path.span) { </del> <ins> .sub_span_of_token(item.span, token::BinOp(token::Star)); if !self.span.filter_generated(sub_span, item.span) { </ins> self.dumper.use_glob(UseGlobData { span: sub_span.expect("No span found for use glob"), id: item.id,

Discussion:
Running on the following code: The output is: I would expect a line containing information about the imports inserted by the compiler, namely and . This used to work in the past.
cc
cc I wonder if one of the changes to name resolution could have caused this? I can't really imagine how, but it seems the most likely candidate.
This was caused by , which (correctly) changed the span of the path in a glob import to not include the suffix. The span change caused  to be so that the call to on the following line always returned true.
Unrelated to this issue, but we currently only dump glob-imported names that end up getting used. would you prefer we dump all glob imported names, even if they are not used?
Thanks ! The intended behviour is just to have the used names, i.e., the list of names one would use if you wanted to replace the glob import with a list import.
Ah, that makes sense. I was thinking more along the lines of refactoring away a needless qualification or moving a path from one module to another, in which we would want to know about unused names as well.
After the changes, I still can reproduce the issue :disappointed:
the changes haven't made it into the nighties yet (the current nightly is still 2016-04-28). If you can reproduce on a more up-to-date local build, could you include the and the emitted json?
Oops... Sorry, I thought the changes were already in nightly. My bad.
No problem!
Change:
.take() .map(|p| cmd_finder.must_have(p)) .or_else(|| env::var_os("BOOTSTRAP_PYTHON").map(PathBuf::from)) // set by bootstrap.py <del> .or_else(|| Some(cmd_finder.must_have("python"))); </del> <ins> .or_else(|| cmd_finder.maybe_have("python")) .or_else(|| cmd_finder.maybe_have("python3")) .or_else(|| cmd_finder.maybe_have("python2")); </ins> build.config.nodejs = build .config

Discussion:
python: python3: It sounds like python3 is strictly required for LLDB, so we should move this check from to , which will only require instead of both commands. cc label: +E-easy +E-mentor +E-help-wanted +A-rustbuild +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
But not everyone will want to run lldb, right? We only mention /usr/bin/python3 there, we don't actually run it unless lldb tests are run, which is pretty rare. This may still be an OK change, of course.
Sure - but in that case, we hardly need python at all, only for rustdoc tests, and it seems ok to use the system python.
I would actually support requiring Python 3 in any case.
let's please keep discussion about 2 vs 3 in and not relitigate it on each issue that mentions python.
claim
If I understand the issue here correctly, just moving the check from to the doesn't entirely remove the issue of needing the name defined on MacOS given the call to in To resolve this should the check in include a MacOS specific check for or an additional check for ?
The former - it should just use any time it needs python on MacOS, and remove the existing check for on that platform.
About to raise a PR, but is it even necessary to perform any check in if we are always forcing in Are there instances where won't be called before ? Also first time using , what would be the correct test to run here?
I don't think it's necessary to check in both places, no, you can return /usr/bin/python3 unconditionally in (). Whether you can remove the check in is a question for - I think probably yes, since you can still run the build without python, but it doesn't necessarily need to go in the same change switching to /bin/python3 consistently. Basically everything runs the check in , but I think it's only relevant when BOOTSTRAP_PYTHON is unset, so probably you'll need to make sure the check executes. If you want to check the version of python used works, you can run .

If we can rely on /usr/bin/python3 always existing on macOS there's no need to check for it, but I would expect that the code in isn't platform-specific and so should continue to look for python in a variety of ways (likely the same ways across all platforms). It looks like python is currently used for two separate things: lldb tests, and docck. The latter likely works with python 2 and python 3, or at least, so it's likely that we need to leave the discovery and configuration in place. Certainly on e.g. Windows /usr/bin/python3 is not expected to exist, I believe.
Change:
// except according to those terms. // xfail-test Can't use syntax crate here <del> #[feature(quote_expr)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod syntax;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
let args_array = self.ecx.expr_vec(self.macsp, fmt_args); let args_slice = self.ecx.expr_addr_of( self.macsp, <del> if nicely_ordered { </del> <ins> if no_need_for_match { </ins> args_array } else { <del> // In the !nicely_ordered case, none of the exprs were moved </del> <ins> // In the !no_need_for_match case, none of the exprs were moved </ins> // away in the previous loop. // // This uses the arg span for `&arg` so that borrowck errors

Discussion:
This has already tripped up some people which seem to get quite confused with this error message, so I'd rather we not regress here: I tried this code: I expected to see this happen: Code compiles fine: the type of is . Instead, this happened: The type of is not send, since the backing state-machine generator produced for it now captures part of the internals involving a reference to the , which is not . It most recently worked on: beta : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Might be related to / ?
I was also suspecting one of those, although I have to admit not having looked into it any further
Does it work with btw ? That should completely disable drop range tracking. (I've launched a try build there so that we have artifacts ready for that soon). There were also recent changes in the formatting macros/machinery last week IIRC. That could be related as well. This should be easy enough to bisect, and make sure where the regression is coming from.
Answering my own questions: doesn't change this, my guess is that it's actually unrelated to initially landed as part of and that rollup's commit doesn't reproduce the issue the change I mentioned was and its commit does reproduce the issue. This PR seems to have caused it indeed.
Nice investigation
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
<ins> error[E0658]: mutable references are not allowed in constant functions --> $DIR/issue-114994-fail.rs:6:27 | LL | const fn use_mut_const_fn(_f: &mut fn(&mut String)) { |                           ^^ | = note: see issue #57349 <https://github.com/rust-lang/rust/issues/57349> for more information = help: add `#![feature(const_mut_refs)]` to the crate attributes to enable error[E0658]: mutable references are not allowed in constant functions --> $DIR/issue-114994-fail.rs:10:33 | LL | const fn use_mut_const_tuple_fn(_f: (fn(), &mut u32)) { |                                 ^^ | = note: see issue #57349 <https://github.com/rust-lang/rust/issues/57349> for more information = help: add `#![feature(const_mut_refs)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
Proposing to extract this from . The following examples shouldn't error: While this has been considered part of for a while, it's also been acknowledged as a bug and suggested by to address separately ahead of stabilizing . Indeed it's surprising for users that this would count as handling a mutable reference in const contexts. See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc Fixing this requires changing to skip traversing things inside function pointers. I'm not sure what the best way to achieve that is.
claim
Is there any reason returning a function trait object (e.g. , , etc.) does not work? It works with the feature, but IMO it should have been pulled out like the function pointers. For example this does not compile:
We didn't exhaustively look through all cases that we can exempt here. Anyway, is on the , so this question will be moot soon. :)
Change:
| LL | global_asm!(""); | ^^^^^^^^^^^^^^^ <del> | = note: this error originates in the macro `global_asm` (in Nightly builds, run with -Z macro-backtrace for more info) </del> error: aborting due to 2 previous errors

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
if let ty::Ref(_, ref_ty, _) | ty::RawPtr(ref_ty, _) = ty.kind() && let ty::Slice(..) = ref_ty.kind() <ins> // The user may have written a predicate like `[T]: Sized` in their where clauses, // which makes slices scalars. && self.places[place].value_index.is_none() </ins> { <del> assert!(self.places[place].value_index.is_none(), "slices are not scalars"); </del> // Prepend new child to the linked list. let len = self.places.push(PlaceInfo::new(Some(TrackElem::DerefLen))); self.places[len].next_sibling = self.places[place].first_child;

Discussion:
File: season two 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
cc
I cannot reproduce the original anymore, but does reproduce. The body is impossible because of the where clauses, so no MIR opts should ever run on it... I'll take a look.
I can still reproduce this with the original mvce when I use the flags that I listed.
bisected with searched nightlies: from nightly-2023-09-01 to nightly-2023-10-01 regressed nightly: nightly-2023-09-09 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.8 cc oli was right:
The bisection here isn't useful sadly, but thank you anyways. I took a look and yeah, the issue is what I suspected. () checks whether there are any impossible predicates (like here). It sadly has to filter out "non-global" predicates, which belongs to. It has to do this because of overflows as mentioned above. told me that the new trait solvers non-fatal handling of overflow will allow this to be fixed. But until then, there's nothing we can do. As for getting the code working, the solution here so to avoid these impossible bounds wherever possible. In the example here, that's easy to do, just delete it. In that's a bit more annoying, I don't really see a solution. We could try playing whack-a-mole by trying to make the MIR opts sorta-handle these cases that slip through, but I don't think that's very sustainable. Might work at least for the trivial cases like though, but I don't open PRs for that.
another one
I'm afraid that this has reached stable with 1.78. I couldn't reproduce it with the minimal example in the previous comment, but a crate of mine now fails on stable, but compiled fine on 1.77.2: <details<summaryfull output</summary</detailsThe code responsible for this is fairly simple: Removing that impl makes the crate compile again.

Will we still just wait for the new solver, now that it's a stable-stable regression?
I managed to minimize the example from : (, ICE in release mode)
Change:
var hideMethodDocs = getSettingValue("auto-hide-method-docs") === "true"; var hideImplementors = getSettingValue("auto-collapse-implementors") !== "false"; <ins> var hideImplementations = getSettingValue("auto-hide-trait-implementations") !== "false"; </ins> var hideLargeItemContents = getSettingValue("auto-hide-large-items") !== "false"; <del> onEachLazy(document.getElementsByTagName("details"), function (e) { var showLargeItem = !hideLargeItemContents && hasClass(e, "type-contents-toggle"); var showImplementor = !hideImplementors && hasClass(e, "implementors-toggle"); if (showLargeItem || showImplementor) { </del> <ins> function openImplementors(id) { var list = document.getElementById(id); if (list !== null) { onEachLazy(list.getElementsByClassName("implementors-toggle"), function(e) { e.open = true; }); } } if (!hideImplementations) { openImplementors("trait-implementations-list"); openImplementors("blanket-implementations-list"); } if (!hideImplementors) { openImplementors("implementors-list"); } onEachLazy(document.getElementsByClassName("rustdoc-toggle"), function (e) { if (!hideLargeItemContents && hasClass(e, "type-contents-toggle")) { </ins> e.open = true; } if (hideMethodDocs && hasClass(e, "method-toggle")) {

Discussion:
beta and nightly ignore the default-on configuration of "Auto-hide trait implementation documentation" On stable  looks like: ! While it looks like: ! And (as of 2021-05-17): ! Going to and toggling "Auto-hide trait implementation documentation" off makes stable look the same as beta, so it definitely seems like beta/nightly are just ignoring this toggle.
This is due to the refactoring we've been doing with the expand / collapse toggles, wrapping them in tags. The code that expands and collapses them based on settings is here: You can see there's an entry for handling "implementors" but not one for "implementations." Right now, both implementors and implementations get wrapped in a tag with . We need to update this Rust code: So that it generates for implementors and for implementations. And then update the JS to add a clause for implementations.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I'm having trouble figuring out what fields to check in to figure out if we're rendering an implementor or an implementation. If someone's able to point me in the right direction I'd appreciate it!
Well, I think I handled it in (funny that I was noticed it and fixed it on my side and someone else find it out too).
Change:
mod sip; use std::default::Default; <del> use std::hash::{Hash, Hasher}; </del> <ins> use std::hash::{BuildHasher, Hash, Hasher}; </ins> use std::rc::Rc; struct MyHasher {

Discussion:
From 1.55 crater run , : a generic method to the trait, making it no longer object safe. This only caused one crate in crater to fail, and the source for that crate seems to have been removed from github. Still, I don't think this is technically allowed breakage. modify labels: +regression-from-stable-to-beta -regression-untriaged +T-libs +I-nominated cc
I think this just needs a on that method, no? Probably was just overlooked during review.
Change:
return false; } inner_expr = inner; <ins> if let Some(inner_type) = typeck_result.node_type_opt(inner.hir_id) { if matches!(inner_type.kind(), ty::RawPtr(..)) { is_raw_ptr = true; break; } } </ins> } <del> if inner_expr.span.lo() != expr.span.lo() { </del> <ins> // Cloning the raw pointer doesn't make sense in some cases and would cause a type mismatch error. (see #126863) if inner_expr.span.lo() != expr.span.lo() && !is_raw_ptr { // Remove "(*" or "(&" </ins> sugg.push((expr.span.with_hi(inner_expr.span.lo()), String::new())); } <ins> // Check whether `expr` is surrounded by parentheses or not. </ins> let span = if inner_expr.span.hi() != expr.span.hi() { // Account for `(*x)` to suggest `x.clone()`. <del> expr.span.with_lo(inner_expr.span.hi()) </del> <ins> if is_raw_ptr { expr.span.shrink_to_hi() } else { // Remove the close parenthesis ")" expr.span.with_lo(inner_expr.span.hi()) } </ins> } else { <ins> if is_raw_ptr { sugg.push((expr.span.shrink_to_lo(), "(".to_string())); suggestion = ").clone()".to_string(); } </ins> expr.span.shrink_to_hi() }; sugg.push((span, suggestion));

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.