jiebi/CodeConvo huggingface dataset:
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 == TrFailedMsg(format!("{} '{}'", failed_msg, expected))); </del> <ins> assert_eq!(result, TrFailedMsg(failed_msg.to_string())); } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251) #[test] #[cfg(not(target_os = "emscripten"))] fn test_should_panic_non_string_message_type() { use crate::tests::TrFailedMsg; fn f() { panic!(1i32); } let expected = "foobar"; let failed_msg = format!(r#"expected panic with string value, found non-string value: `{:?}` expected substring: `"foobar"`"#, TypeId::of::<i32>()); let desc = TestDescAndFn { desc: TestDesc { name: StaticTestName("whatever"), ignore: false, should_panic: ShouldPanic::YesWithMessage(expected), allow_fail: false, test_type: TestType::Unknown, }, testfn: DynTestFn(Box::new(f)), }; let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; assert_eq!(result, TrFailedMsg(failed_msg)); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)

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:
parallel!(impl $fblock [$block, $($c,)*] [$($rest),*]) }; (impl $fblock:block [$($blocks:expr,)*] []) => { <del> ::rustc_data_structures::sync::scope(|s| { $(let block = rustc_data_structures::sync::FromDyn::from(|| $blocks); s.spawn(move |_| block.into_inner()());)* (|| $fblock)(); </del> <ins> $crate::sync::parallel_guard(|guard| { $crate::sync::scope(|s| { $( let block = $crate::sync::FromDyn::from(|| $blocks); s.spawn(move |_| { guard.run(move || block.into_inner()()); }); )* guard.run(|| $fblock); }); </ins> }); }; ($fblock:block, $($blocks:block),*) => { <del> if rustc_data_structures::sync::is_dyn_thread_safe() { </del> <ins> if $crate::sync::is_dyn_thread_safe() { </ins> // Reverse the order of the later blocks since Rayon executes them in reverse order // when using a single thread. This ensures the execution order matches that // of a single threaded rustc.

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
]; for (a, b) in expected.iter().zip(filtered) { <del> assert!(*a == b.desc.name.to_string()); </del> <ins> assert_eq!(*a, b.desc.name.to_string()); </ins> } }

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:
rscope.anon_regions(span, expected_num_region_params); if supplied_num_region_params != 0 || anon_regions.is_err() { <del> span_err!(tcx.sess, span, E0107, "wrong number of lifetime parameters: expected {}, found {}", expected_num_region_params, supplied_num_region_params); </del> <ins> report_lifetime_number_error(tcx, span, supplied_num_region_params, expected_num_region_params); </ins> } match anon_regions {

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.
Change:
# whether to set it as rustc's default linker on `x86_64-unknown-linux-gnu`. This will also only be # when *not* building an external LLVM (so only when using `download-ci-llvm` or building LLVM from # the in-tree source): setting `llvm-config` in the `[target.x86_64-unknown-linux-gnu]` section will <del> # make this default to false. </del> <ins> # make this default to false. </ins> #lld = false in all cases, except on `x86_64-unknown-linux-gnu` as described above, where it is true # Indicates whether LLD will be used to link Rust crates during bootstrap on

Discussion:
With the latest , when I run a run-make test twice in a row, bootstrap rebuilds and : This has to be a recent regression, it didn't happen until ~yesterday. Confirmed with that it also happens for them.
Sounds suspiciously similar to
Yeah this is again caused by being enabled :laughing: Do you think that there's some more general solution to the rebuild problem?
Thanks for notifying me about this. I am travelling this weekend, meaning i might not have a chance to thoroughly investigate before Monday. (But I will at the latest be able to look on Monday). The last time it was due to dependency on the same crates with different rustflags. One from llbc-linker and one from some other tool (rustdoc?). The two different invocations maps to the same cache entry but is invalid between each other and thus triggers a rebuild. The solution last time was to mimic the rustflags being used other places in llbc-linker. That might be a good short term solution now as well. I don't know about the long term solution but it seems like either caching multiple versions of a crate or unifying the rustflag somewhere might be alternatives?
Of course, there's no rush, I just wanted to let you know, given that you already have some experience in debugging this :laughing: This seems rather brittle though, as you mention. I wonder what's so unique about this tool that it causes these rebuilds so often. You mentioned that we cannot share flags between all Step invocations. But maybe it would make sense to better share flags between at least this tool and other steps, rather than hardcoding selected flags? (as was done last time with the parallel compiler).
Actually, I wonder if we really need to enable this linker by default in all four bootstrap profiles.
Sure, seems fine to me. I didn't expect it to be a problem this frequently.
posted instead to disable this flag by default, I don't think it should be enabled for most contributors.
Change:
if let Some(ref init) = local.init { let init_ty = self.check_decl_initializer(local, &init); <del> if init_ty.references_error() { self.write_ty(local.hir_id, init_ty); } </del> <ins> self.overwrite_local_ty_if_err(local, t, init_ty); </ins> } self.check_pat_top(&local.pat, t, None); let pat_ty = self.node_ty(local.pat.hir_id); <del> if pat_ty.references_error() { self.write_ty(local.hir_id, pat_ty); </del> <ins> self.overwrite_local_ty_if_err(local, t, pat_ty); } fn overwrite_local_ty_if_err(&self, local: &'tcx hir::Local, decl_ty: Ty<'tcx>, ty: Ty<'tcx>) { if ty.references_error() { // Override the types everywhere with `types.err` to avoid knock down errors. self.write_ty(local.hir_id, ty); self.write_ty(local.pat.hir_id, ty); let local_ty = LocalTy { decl_ty, revealed_ty: ty, }; self.locals.borrow_mut().insert(local.hir_id, local_ty); self.locals.borrow_mut().insert(local.pat.hir_id, local_ty); </ins> } }

Discussion:
Because of the method error, doesn't get a type (not even , AFAICT), and then it gets inferred to from another call in the function, which results in the unsized variable error.
cc
I'd expect a simple fix for this would be to actually set as 's type, so it can't be inferred to anything else, although that could make other errors less informative.
I just spent a lot of time looking at a error. The errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings. Because was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it when this other similar type similar is?", "how can I find out if a type is " and so on. I don't know if works like that, but in this case it might be better to assume that the type implements any trait it's required to.
That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet
I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.
I just reread, and: That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The error is a mere side-effect.
The underlying cause is that we have two maps for →, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.
Change:
<ins> error[E0118]: no nominal type found for inherent implementation --> $DIR/E0118-2.rs:3:6 | LL | impl &mut Foo { |      ^^^^^^^^ impl requires a nominal type | = note: either implement a trait on it or create a newtype to wrap it instead = note: you could also try moving the reference to uses of `Foo` (such as `self`) within the implementation error: aborting due to previous error For more information about this error, try `rustc --explain E0118`. </ins>

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
}) .collect::<Vec<_>>(); <del> doc_std( builder, DocumentationFormat::HTML, stage, target, &out, &extra_args, &requested_crates, ); </del> <ins> doc_std(builder, self.format, stage, target, &out, &extra_args, &requested_crates); // Don't open if the format is json if let DocumentationFormat::JSON = self.format { return; } </ins> // Look for library/std, library/core etc in the `x.py doc` arguments and // open the corresponding rendered docs.

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
: Exclusive or. Calls the `bitxor` method of the `std::ops::BitXor` trait. * `<<` <del> : Logical left shift. </del> <ins> : Left shift. </ins> Calls the `shl` method of the `std::ops::Shl` trait. * `>>` <del> : Logical right shift. </del> <ins> : Right shift. </ins> Calls the `shr` method of the `std::ops::Shr` trait. #### Lazy boolean operators

Discussion:
The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.
Change:
}; for elem in place_ref.projection[base..].iter() { cg_base = match elem.clone() { <del> mir::ProjectionElem::Deref => bx.load_operand(cg_base).deref(bx.cx()), </del> <ins> mir::ProjectionElem::Deref => { // custom allocators can change box's abi, making it unable to be derefed directly if cg_base.layout.ty.is_box() && matches!(cg_base.layout.abi, Abi::Aggregate { .. } | Abi::Uninhabited) { let ptr = cg_base.project_field(bx, 0).project_field(bx, 0); bx.load_operand(ptr).deref(bx.cx()) } else { bx.load_operand(cg_base).deref(bx.cx()) } } </ins> mir::ProjectionElem::Field(ref field, _) => { cg_base.project_field(bx, field.index()) }

Discussion:
Hello, I've tested the feature and encountered an ICE: If tried this code (): I've used the "current" playground nighty compiler, but I can reproduce locally. : and also on <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label: +requires-nightly +A-allocators
Slightly minimized: Doesn't ICE anymore if you either remove the field or if it is not an array.
Duplicate of ?
No, not really a duplicate (but possibly related). This issue and the linked one have completely different backtraces.
Just by the way, using inline storage in an allocator is actually unsafe unless the impl of the trait is using a reference. See the Allocator safety notes: (Emphasis mine) ()
FWIW this is also triggered with uninhabited types. Though looks like only when drop glue is involved. Eg works but doesn't.
Another MCVE that leads to this ICE: found in
claim
Change:
bundle.set_use_isolating(with_directionality_markers); // If the user requests the default locale then don't try to load anything. <del> if !requested_fallback_locale && let Some(requested_locale) = requested_locale { </del> <ins> if let Some(requested_locale) = requested_locale { </ins> let mut found_resources = false; for sysroot in user_provided_sysroot.iter_mut().chain(sysroot_candidates.iter_mut()) { sysroot.push("share");

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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.
Change:
<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub fn function_with_str<const STRING: &'static str>() -> &'static str { STRING } pub fn function_with_bytes<const BYTES: &'static [u8]>() -> &'static [u8] { BYTES } pub fn main() { assert_eq!(function_with_str::<"Rust">(), "Rust"); assert_eq!(function_with_str::<"ℇ㇈↦">(), "ℇ㇈↦"); assert_eq!(function_with_bytes::<b"AAAA">(), &[0x41, 0x41, 0x41, 0x41]); assert_eq!(function_with_bytes::<{&[0x41, 0x41, 0x41, 0x41]}>(), b"AAAA"); } </ins>

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
// run-fail <del> // error-pattern:panicked at 'Box<Any>' </del> <ins> // error-pattern:panicked at 'Box<dyn Any>' </ins> // ignore-emscripten no processes #![feature(box_syntax)]

Discussion:
() I would’ve expected it to say Relevant point in seems to be . label C-enhancement, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-error-handling
claim
Wow, issues really do go fast. Best of luck, reaganmcf!