jiebi/CodeConvo huggingface dataset:
Change:
$EndFeature, " ```"), <del> #[unstable(feature = "saturating_neg", issue = "59983")] </del> <ins> #[stable(feature = "saturating_neg", since = "1.45.0")] </ins> #[rustc_const_unstable(feature = "const_saturating_int_methods", issue = "53718")] #[inline] pub const fn saturating_neg(self) -> Self {

Discussion:
It would be great to have and functions for signed integer types. The current work-around is using a pattern like but having explicit functions would lift the corner-case knowledge "burden" from the user.
What do you expect them to return? Just for the two values that can't be expressed? IMHO you should prefer the instead and explicitly handle that.
The and functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type. The / variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing functions. asserteq!(127i8.saturatingabs(), 127); asserteq!(-127i8.saturatingabs(), 127); asserteq!(-128i8.saturatingabs(), 127); asserteq!(127i8.saturatingneg(), -127); asserteq!(-127i8.saturatingneg(), 127); asserteq!(-128i8.saturating_neg(), 127);
These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says. By using they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the approach.
Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.
What's holding up stabilization on this? It seems relatively simple.
In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.
Change:
self.draw_code_line( &mut buffer, &mut row_num, <del> highlight_parts, </del> <ins> &highlight_parts, </ins> line_pos + line_start, line, show_code_change,

Discussion:
The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"<!-- 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. --: also on stable: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Change:
use rustc_infer::infer::{self, InferCtxt, SubregionOrigin}; use rustc_middle::mir::ConstraintCategory; use rustc_middle::ty::subst::GenericArgKind; <ins> use rustc_middle::ty::TypeFoldable; </ins> use rustc_middle::ty::{self, TyCtxt}; use rustc_span::DUMMY_SP;

Discussion:
Hello, I am getting an ICE while "playing" with  MCVE can be found here: <details<summaryOriginal</summary</details<!-- 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 Playground) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
A project maintainer might want to add the label.
Reduced, no nightly features: Output on stable: ICEs on beta and nightly.
Adding a bound as suggested gives this ICE on stable: <details<summaryBacktrace</summary</detailsWhich looks like . It still gives the original ICE on beta and stable, and it looks like 's code now produces the original ICE of this issue on beta and stable. Does that make this a duplicate?
:
modify labels: -F-unboxed_closures -requires-nightly per
This is now reproducing on stable. This feels like more of a "guts of the borrow checker" kind of issue than async/await-specific, so I'm tagging with .
Assigning as and removing .
Another repro from :
Change:
= help: add `#![feature(function)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'function' <del> --> $DIR/internal-unstable.rs:41:10 </del> <ins> --> $DIR/internal-unstable.rs:42:10 </ins> | LL |     bar!(internal_unstable::unstable()); |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
fn main() { let _ = env!("NON_UNICODE_VAR"); <ins> let _ = option_env!("NON_UNICODE_VAR"); </ins> }

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .
Change:
"itertools 0.8.0", "lazy_static 1.4.0", "matches", <del> "pulldown-cmark 0.6.1", </del> <ins> "pulldown-cmark 0.7.0", </ins> "quine-mc_cluskey", "regex-syntax", "semver",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
.ok()?; dest.into() } <del> CastKind::FnPtrToPtr | CastKind::PtrToPtr | CastKind::PointerCoercion( </del> <ins> CastKind::FnPtrToPtr | CastKind::PtrToPtr => { let src = self.evaluated[value].as_ref()?; let src = self.ecx.read_immediate(src).ok()?; let to = self.ecx.layout_of(to).ok()?; let ret = self.ecx.ptr_to_ptr(&src, to).ok()?; ret.into() } CastKind::PointerCoercion( </ins> ty::adjustment::PointerCoercion::MutToConstPointer | ty::adjustment::PointerCoercion::ArrayToPointer | ty::adjustment::PointerCoercion::UnsafeFnPointer,

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=5 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ()'', 'thread 'rustc' panicked at 'assertion failed: ()'' 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: [optimizedmir] optimizing MIR for [collectandpartitionmonoitems] collectandpartitionmono_items --
cc
Change:
<ins> #![crate_name = "foo"] // @has foo/fn.f.html // @has - '//*[@class="rust fn"]' 'pub fn f(0u8 ...255: u8)' pub fn f(0u8...255: u8) {} </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. --code is from <!-- 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
label -T-compiler +T-rustdoc
The playground's nightly compiler doesn't ICE on this example. Are you able to confirm this with the latest nightly?
rustdoc is crashing, not the compiler itself. Playground doesn't have a button for running rustdoc.
MCVE: Marking as P-medium since this happens on valid code.

<!-- 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. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:
Change:
<ins> error[E0107]: missing generics for associated type `C::DType` --> $DIR/issue-81712-cyclic-traits.rs:14:10 | LL |     type DType<T>: D<T, CType = Self>; |          ^^^^^ expected 1 type argument | note: associated type defined here, with 1 type parameter: `T` --> $DIR/issue-81712-cyclic-traits.rs:14:10 | LL |     type DType<T>: D<T, CType = Self>; |          ^^^^^ - help: use angle brackets to add missing type argument | LL |     type DType<T><T>: D<T, CType = Self>; |               ^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </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. --This ICE is related to : <!-- 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</detailsIdeally, would compile, but generic associated types in trait paths are currently not implemented. Maybe rustc could give a nice error message when the is missing.
Duplicate to and related heavily to others. But this has a nice minimal repro, so worth leaving open. Probably fixed by .
I've tested this locally and I can confirm that fixes this (with this change: ).
Change:
#[unstable(feature = "step_trait", reason = "recently redesigned", issue = "42168")] impl Step for $u_wider { step_identical_methods!(); <ins> step_unsigned_methods!(); </ins> #[inline] fn steps_between(start: &Self, end: &Self) -> Option<usize> {

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
- CI_JOB_NAME: dist-x86_64-mingw MSYS_BITS: 64 SCRIPT: python x.py dist <del> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-full-tools </del> <ins> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-full-tools --enable-profiler </ins> MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror MINGW_ARCHIVE: x86_64-6.3.0-release-posix-seh-rt_v5-rev2.7z MINGW_DIR: mingw64

Discussion:
I am trying to see if -Z pgo-gen is available on Windows-Gnu: I am using: I am using a very small Rust test program: If I compile with: rustc -Z pgo-gen It gives me: error: debugging option requires a string (Z pgo-gen=<value) If I compile with (using a random string?): rustc -Z pgo-gen=abc It gives me: error[E0463]: can't find crate for
Hi, I was also struggling with that! :) The is supposed to be the profile file which details are written into after executing the pgo-gen instrumented binary and details are read from when building the binary for the second time with pgo-use. So  might work :)
I've tried to do as you say, but perhaps I am doing something wrong. I've created a binary project with cargo (just the hello world), then I've set the variable: Then I've compiled: It gives me:
Hm, I'm not sure what is going on there now (I also can't reproduce since not a windows user), sorry :/
Using: Calling rustc directly gives:
GNU toolchain is built without profiler:
I wonder if we could just enable the profiler on .
I think I can find time this week to test it. I'm almost sure PGO was broken on some older GCC version but I cannot recall the details.
Status update: I've got it working few days ago but pushing this upstream is blocked on upgrading to 0.1.15. It was meant to be done by but was backed off.
Change:
let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result != TrOk); </del> <ins> assert_ne!(result, TrOk); </ins> } #[test]

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.
Change:
error[E0532]: expected tuple struct or tuple variant, found unit variant `Color::NoColor` --> $DIR/match-pattern-field-mismatch-2.rs:12:11 | <ins> LL |         NoColor, |         ------- `Color::NoColor` defined here ... </ins> LL |           Color::NoColor(_) => { } <del> |           ^^^^^^^^^^^^^^ not a tuple struct or tuple variant </del> <ins> |           ^^^^^^^^^^^^^^^^^ help: use this syntax instead: `Color::NoColor` </ins> error: aborting due to previous error

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
<ins> enum Bug { V1 = return [0][0] //~ERROR return statement outside of function body } fn main() {} </ins>

Discussion:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.
Change:
0 -1px 0 black; } <del> .module-item .stab { </del> <ins> .module-item .stab, .import-item .stab { </ins> border-radius: 3px; display: inline-block; font-size: 80%;

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
inside_public_path: bool, exact_paths: DefIdMap<Vec<Symbol>>, modules: Vec<Module<'tcx>>, <ins> is_importable_from_parent: bool, </ins> } impl<'a, 'tcx> RustdocVisitor<'a, 'tcx> {

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink: