jiebi/CodeConvo huggingface dataset:
Change:
#![feature(ordering_chaining)] #![feature(result_unwrap_or_default)] #![feature(ptr_unaligned)] <ins> #![feature(move_cell)] </ins> extern crate core; extern crate test;

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
Change:
run_lints!(cx, check_crate, late_passes, krate); hir_visit::walk_crate(cx, krate); <ins> run_lints!(cx, check_crate_post, late_passes, krate); </ins> }); // If we missed any lints added to the session, then there's a bug somewhere

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
valopt nacl-cross-path  "" "NaCl SDK path (Pepper Canary is recommended). Must be absolute!" valopt release-channel "dev" "the name of the release channel to build" valopt musl-root "/usr/local" "MUSL root installation directory" <ins> valopt extra-filename "" "Additional data that is hashed and passed to the -C extra-filename flag" </ins> # Used on systems where "cc" and "ar" are unavailable valopt default-linker "cc" "the default linker"

Discussion:
Some systems, like Gentoo, want to package multiple versions of the Rust compiler along side each other. There are several obstacles to this, but the obvious one is that the installed Rust crates need to not have conflicting names. While we have a mechanism for this , the extra strings appended by the current makefile are not sufficient to discriminate between arbitrary compiler revisions. Most likely we will add a configure switch that specifies an additional string to hash into the filename extra, in addition to what we're already hashing. re
Change:
} // FIXME: We make sure that this is a normal top-level binding, <del> // but we could suggest `todo!()` for all uninitalized bindings in the pattern pattern </del> <ins> // but we could suggest `todo!()` for all uninitialized bindings in the pattern pattern </ins> if let hir::StmtKind::Let(hir::LetStmt { span, ty, init: None, pat, .. }) = &ex.kind && let hir::PatKind::Binding(..) = pat.kind

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
<ins> //@ compile-flags: --document-private-items --document-hidden-items pub trait TheTrait {} #[doc(hidden)] struct Value {} //@ has '$.index[*][?(@.docs=="THE IMPL")]' /// THE IMPL impl TheTrait for Value {} </ins>

Discussion:
Affected crate: , at path in repo Commit: Building rustdoc JSON with Consider the following type from in that commit: I expected to see this happen: the rustdoc JSON should state that etc. are all implemented for that type. Instead, this happened: none of those traits are listed as implemented for that type. Deleting and rebuilding the rustdoc JSON causes all the missing trait impls to be present again. : The same bug is present on nightly: The bug was first spotted by who filed on for incorrectly reporting that types stopped being etc. Of course we now know this was because those traits were genuinely not present in the underlying rustdoc JSON file. Thanks for all the awesome work you've been doing! It's been absolutely fundamental for .
It should be fixed with
That didn't fix it MCVE: Produces (On )
This is fixed & works just fine as of today
It would be great to make sure we have a regression test case for this before closing the issue, since this is a correctness concern for cargo-semver-checks that would be very difficult to debug if it reoccurs.
Absolutely, that's what I've done in
Change:
/// [`finish`]: Hasher::finish /// [`write`]: Hasher::write /// [`write_u8`]: Hasher::write_u8 <ins> /// [`write_u32`]: Hasher::write_u32 </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Hasher { /// Returns the hash value for the values written so far.

Discussion:
Currently is implemented as . The question is: is it a requirement for all implementations? In other words, is is true, that for each hasher implementation, call must be equivalent to ? (assuming host is little-endian). Why is it important. Suppose, you want to implement very simple hasher with state updated like . If does not have requirement as above, hasher can be implemented by simply casting any operand to and avoiding dealing with unaligned/smaller than u64 integers:
I’m fairly sure there was a discussion about it before and we decided against doing any changes to the libstd impl. Don’t exactly remember the reason, though.
If any decision is made, I wish it would be stated in the documentation of trait.
employs a different implementation to achieve platform-independence.
I don't think there's any such requirement. The in the compiler does exactly what your example does.
I think I would be opposed to this requirement; it imposes a performance penalty for systems of the "wrong" endianness, since they would need to correct their endianness. The only requirement on should be that the same sequence of calls produces the same result, I think.
My spec request: given two byte slices and , is equivalent to ? This way, we could define all the non-slice methods as explicitly being transmutes, always.
removing until lets us know what to document here.
My personal take on this is that we should only guarantee that produces the same value for the exact same sequence of calls. This even applies to plain calls on byte slices: a is only guaranteed to produce the same result if the same sequence of calls are used with the same slice lengths*. For an example of where this could make a difference, consider from Abseil which hashes short slices by reading 0-16 bytes and padding anything not included in the length with zeroes or duplicates of the existing bytes.
Based on the libs team decision in , I'm going to close this issue. The answer to the question in the issue title is no: is not required to be equivalent to 4 calls of .
Was there any updates to the documentation of Hasher? I didn't see any in a quick scan of threads.
Yeah, it seems like the thread was closed because the original idea was decided to not be done, but I agree that it shouldn't be closed until documentation is .

cc who closed this since it shouldn't be closed. Opened to add docs for this, but think this issue should be kept open until we've finally decided on how to document this.
Change:
use rustc_infer::infer::InferCtxt; use rustc_middle::mir::ConstraintCategory; use rustc_middle::traits::query::OutlivesBound; <del> use rustc_middle::ty::{self, RegionVid, Ty}; </del> <ins> use rustc_middle::ty::{self, RegionVid, Ty, TypeVisitableExt}; </ins> use rustc_span::{ErrorGuaranteed, Span, DUMMY_SP}; use rustc_trait_selection::traits::query::type_op::{self, TypeOp}; use std::rc::Rc;

Discussion:
In that commit, go to folder and run (tested in nightly, stable 1.69 and stable 1.70) : <details<summary<strongBacktrace</strong</summary<p</p</details
This is causing us to leak placeholders into implied bounds. Minimized:
Change:
#![l=|x|[b;x ]] //~ ERROR unexpected token: `|x| [b; x]` //~^ ERROR cannot find attribute `l` in this scope <del> //~^^ ERROR attempt to use a non-constant value in a constant [E0435] //~^^^ ERROR cannot find value `b` in this scope [E0425] </del> // notice the space at the start, // we can't attach any attributes to this file because it needs to be at the start

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a few other errors, because the code is nonsense, so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsAlso note how there is one additional error below the backtrace, not sure if that's expected.
Thanks for the bug report, could this be related to the recent HIR map/lowering refactorings?
This issue looks very similar to , but the examples from there don't panic anymore.

<!-- 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. --I got a very large poc file, and reduce it into following code. But after reducing (via a simple delta debugging tech), the code looks kind of confusing. Please let me know if anyone prefers a better-formed but long test-case, and I will try me best to get one. md5: <!-- 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 bug is reproduced with nightly and beta versions, but not with stable version. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This can be "solved" by using and create a instead of panicking.
Assigning as discussed as part of the and removing .
A reproduction with fewer errors:
The provided examples do not panic anymore, can this issue be closed or does it need tests?
lets keep it open purely to track adding regression tests for these.
Change:
param_text.push_str(&ty_to_string(&ty)); if let Some(ref _default) = default { // FIXME(const_generics_defaults): push the `default` value here <del> todo!(); </del> } } if !param.bounds.is_empty() {

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 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</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears
Change:
<del> Subproject commit 4f6f264c305ea30f1de90ad0c2f341e84d972b2e </del> <ins> Subproject commit d77fe6c63ca4c50b207a1161def90c9e57368d5b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
Miri fix at
Change:
use syntax::fold::Folder; use syntax::parse::{self, PResult}; use syntax::util::node_count::NodeCounter; <del> use syntax_pos::FileName; </del> <ins> use syntax_pos::{FileName, hygiene}; </ins> use syntax_ext; use derive_registrar;

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
LL | struct Foo(isize, isize); |        ^^^ = note: the matched value is of type `Foo` <ins> = note: `isize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `isize` matching </ins> help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown | LL ~         Foo(2, b) => println!("{}", b),

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
fn visit_variant(&mut self, var: &'tcx Variant<'tcx>) { self.check_missing_stability(self.tcx.hir().local_def_id(var.id), var.span); <ins> if let Some(ctor_hir_id) = var.data.ctor_hir_id() { self.check_missing_stability(self.tcx.hir().local_def_id(ctor_hir_id), var.span); } </ins> intravisit::walk_variant(self, var); }

Discussion:
Example: . This was fixed by adding stability attributes (), but the general problem remains that was able to land. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Found the bug. PR incoming. claim

As of current nightly rustc 1.65.0-nightly ( 2022-08-10): : Mentioning erstwhile tracking issue Mentioning in connection with .
"encountered unmarked API" &mdash; maybe it's that there is no #[stable] attribute on the enum variants, like there is in other stable enums? I'd have expected that to be caught during the libstd build, so we should fix whatever was supposed to catch it, not just add the attributes.
Indeed, I didn't realize that enum variants also needed stable attributes.
Change:
// Get the interior types and substs which typeck computed let movable = match *gen_ty.kind() { ty::Generator(_, _, movability) => movability == hir::Movability::Movable, <ins> ty::Error(_) => return None, </ins> _ => span_bug!(body.span, "unexpected generator type {}", gen_ty), };

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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
// assembly-output: emit-asm // ignore-tidy-linelength <del> // revisions: aarch64_apple_darwin // [aarch64_apple_darwin] compile-flags: --target aarch64-apple-darwin // [aarch64_apple_darwin] needs-llvm-components: aarch64 // revisions: aarch64_apple_ios // [aarch64_apple_ios] compile-flags: --target aarch64-apple-ios // [aarch64_apple_ios] needs-llvm-components: aarch64 // revisions: aarch64_apple_ios_macabi // [aarch64_apple_ios_macabi] compile-flags: --target aarch64-apple-ios-macabi // [aarch64_apple_ios_macabi] needs-llvm-components: aarch64 // revisions: aarch64_apple_ios_sim // [aarch64_apple_ios_sim] compile-flags: --target aarch64-apple-ios-sim // [aarch64_apple_ios_sim] needs-llvm-components: aarch64 // revisions: aarch64_apple_tvos // [aarch64_apple_tvos] compile-flags: --target aarch64-apple-tvos // [aarch64_apple_tvos] needs-llvm-components: aarch64 // revisions: aarch64_apple_tvos_sim // [aarch64_apple_tvos_sim] compile-flags: --target aarch64-apple-tvos-sim // [aarch64_apple_tvos_sim] needs-llvm-components: aarch64 // revisions: aarch64_apple_watchos // [aarch64_apple_watchos] compile-flags: --target aarch64-apple-watchos // [aarch64_apple_watchos] needs-llvm-components: aarch64 // revisions: aarch64_apple_watchos_sim // [aarch64_apple_watchos_sim] compile-flags: --target aarch64-apple-watchos-sim // [aarch64_apple_watchos_sim] needs-llvm-components: aarch64 </del> // revisions: aarch64_be_unknown_linux_gnu // [aarch64_be_unknown_linux_gnu] compile-flags: --target aarch64_be-unknown-linux-gnu // [aarch64_be_unknown_linux_gnu] needs-llvm-components: aarch64

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.
Change:
<ins> // run-pass #![allow(unused_macros)] macro_rules! foo { ($x:pat | $y:pat) => {} } // should be ok macro_rules! bar { ($($x:pat)+ | $($y:pat)+) => {} } // should be ok macro_rules! qux { ($x:pat, $y:pat) => {} } // should be ok macro_rules! match_any { ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => { // should be ok match $expr { $( $( $pat => $expr_arm, )+ )+ } }; } fn main() { let result: Result<i64, i32> = Err(42); let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into()); assert_eq!(int, 42); } </ins>

Discussion:
In Edition 2021, the following should error: for the same reason that the following already errors: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was wondering if you were interested in fixing this as a follow-up to -- I don't think you included it in that PR, right?
claim
I think the problem is here: , but if we allow , then will also be allowed. This does not seem right. But in the current function we can't yet tell what token comes next in . Do you have any suggestions?
Actually, the code may already be correct? It appears that is not allowed for , which is the goal: Maybe we just need a test -- or maybe there already is one!
Yes this part of the logic I have , but my question is about . I will add an additional test for pat2021.
I expect to be an error -- it is, right?
Yes. I see what you mean. I misunderstood your description in the issue.