jiebi/CodeConvo huggingface dataset:
Change:
return "Vec(size={})".format(self.length) def children(self): <del> saw_inaccessible = False for index in xrange(self.length): element_ptr = self.data_ptr + index if saw_inaccessible: return try: # rust-lang/rust#64343: passing deref expr to `str` allows # catching exception on garbage pointer str(element_ptr.dereference()) yield "[{}]".format(index), element_ptr.dereference() except RuntimeError: saw_inaccessible = True yield str(index), "inaccessible" </del> <ins> return _enumerate_array_elements( self.data_ptr + index for index in xrange(self.length) ) </ins> @staticmethod def display_hint():

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
<ins> // run-pass // ^-- The above is needed as this issue is related to LLVM/codegen. // min-llvm-version:15.0.0 // ^-- The above is needed as this issue is fixed by the opaque pointers. fn main() { type_error(|x| &x); } fn type_error<T>( _selector: for<'a> fn(&'a Vec<Box<dyn for<'b> Fn(&'b u8)>>) -> &'a Vec<Box<dyn Fn(T)>>, ) { } </ins>

Discussion:
I may have found a bug in the compiler. The entirety of the code to reproduce this bug is this: The program should build successfully, assuming the rustc type checker does not detect any errors at the level of the Rust type system. The rustc type checker seems happy with the program. However, presumably after the LLVM IR generation phase, and during some IR verification phase, I get this type error:
Reduced:
I thought we already fixed that by adding casts. One possible fix that might be less harmful would be to give all types that are subtyping-equivalent the same LLVM type. They should be having the same layout anyway, and their fields should be subtyping-equivalent (because that's what subtyping-equivalence means). The other option would be to insert casts when subtyping is taking place.
This looks like a new instance of . cc
was just an instance of the general problem, we just started generating named types for trait objects then, which made the problem show up in more cases. I agree with first proposal, i.e. destroy the distinction ahead of time. We're only wasting time by inserting casts and LLVM wastes time ignoring those casts (insert rant about how counterproductive LLVM's types are).
Reduced to its essence:
An example that my previous approach will not make compile (but currently gives an ICE outputtypeparametermismatch):
Nah you can do it without an ICE, but you're still within deep ICE territory
This is making me suspect, that when we get higher-ranked type bounds, finding a "canonical form for subtyping" will be impossible (note: don't be so sure. You can't? (shouldn't?) have higher-ranged type bounds in trait objects, so life might be better). Might as well insert casts. Note that my old approach has problems with anonymization in invariant types:
marking this as p-medium as per the
labels +T-types This seems like a problem around higher ranked normalization etc, so we are tagging as T-types. We think it may have been fixed as a side-effect of some LLVM change or other (cc for the details).
Seems to be fixed since 1.23.
Triage: The issue hasn't been fixed actually, at least on CI (CI stderr from ):
That's interesting. It doesn't fail in a playground. Is this a debug assert now or something?

The build says so maybe this is fixed with nighty that uses llvm but llvm 13 still causes problems?
Likely, we could use if so. Is there a CI builder that uses a newer LLVM on bors?
Yeah, this is fixed by LLVM using its opaque pointers, so that's why it's possibly broken on LLVM 13?
Re-submitted a PR with :
Change:
pub fn gid(&mut self, id: gid_t) { self.gid = Some(id); } <ins> pub fn groups(&mut self, groups: &[gid_t]) { self.groups = Some(Box::from(groups)); } </ins> pub fn saw_nul(&self) -> bool { self.saw_nul

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
} #[derive(LintDiagnostic)] <del> #[diag(lint_suspicious_double_ref_op)] pub struct SuspiciousDoubleRefDiag<'a> { pub call: Symbol, </del> <ins> #[diag(lint_suspicious_double_ref_deref)] pub struct SuspiciousDoubleRefDerefDiag<'a> { pub ty: Ty<'a>, } #[derive(LintDiagnostic)] #[diag(lint_suspicious_double_ref_clone)] pub struct SuspiciousDoubleRefCloneDiag<'a> { </ins> pub ty: Ty<'a>, <del> pub op: &'static str, </del> } // pass_by_value.rs

Discussion:
If I have a type , and a trait that is implemented for both and , is a valid way to get a reference from an object of type . But since beta 1.71, this emits a warning. I have no idea what the warning is trying to convey, what "double reference" is referring to, or what "the inner type" is. No response
cc
Ah. then I think this lint shouldn't apply to since can mean specifically to borrow . But I think this should still apply to and
(sorry)
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
pub fn target() -> Target { let mut base = super::windows_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> // On Win64 unwinding is handled by the OS, so we can link libgcc statically. base.pre_link_args.push("-static-libgcc".to_string()); base.pre_link_args.push("-m64".to_string());

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
use rustc_hir::{def::Res, ItemKind, Node, PathSegment}; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::{RegionVariableOrigin, TyCtxtInferExt}; <ins> use rustc_infer::traits::Obligation; </ins> use rustc_middle::hir::nested_filter; use rustc_middle::ty::fold::TypeFoldable; use rustc_middle::ty::layout::{LayoutError, MAX_SIMD_LANES}; use rustc_middle::ty::subst::GenericArgKind; use rustc_middle::ty::util::{Discr, IntTypeExt}; <del> use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, ParamEnv, ToPredicate, Ty, TyCtxt}; </ins> use rustc_session::lint::builtin::{UNINHABITED_STATIC, UNSUPPORTED_CALLING_CONVENTIONS}; use rustc_span::symbol::sym; use rustc_span::{self, MultiSpan, Span};

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
}); match tcx.codegen_fulfill_obligation((ty::ParamEnv::reveal_all(), trait_ref)) { <del> traits::VtableImpl(traits::VtableImplData { impl_def_id, .. }) => { </del> <ins> Some(traits::VtableImpl(traits::VtableImplData { impl_def_id, .. })) => { </ins> tcx.coerce_unsized_info(impl_def_id).custom_kind.unwrap() } vtable => {

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
/// `failure` describes the required ordering for the load operation that takes place when /// the comparison fails. Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the successful load <del> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note**: This method is only available on platforms that support atomic operations on #[doc = concat!("[`", $s_int_type, "`].")]

Discussion:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.
Change:
<ins> error: missing `fn` or `struct` for function or struct definition --> $DIR/pub-ident-fn-3.rs:4:8 | LL |     pub bar(); |     ---^--- help: if you meant to call a macro, try: `bar!` error: aborting due to previous error </ins>

Discussion:
Hi, I got the compiler to panic with this invalid code: The panic does not happen when the code is outside . Happens on Backtrace : and also on Backtrace :
First appeared in 1.33.0, 1.32.0 gives this error:
Change:
self.annotate_expected_due_to_let_ty(err, expr, error); self.emit_type_mismatch_suggestions(err, expr, expr_ty, expected, expected_ty_expr, error); self.note_type_is_not_clone(err, expected, expr_ty, expr); <del> self.note_internal_mutation_in_method(err, expr, expected, expr_ty); </del> <ins> self.note_internal_mutation_in_method(err, expr, Some(expected), expr_ty); </ins> self.check_for_range_as_method_call(err, expr, expr_ty, expected); self.check_for_binding_assigned_block_without_tail_expression(err, expr, expr_ty, expected); self.check_wrong_return_type_due_to_generic_arg(err, expr, expr_ty);

Discussion:
In long method chains we might inadvertently call a method that is not meant to be chained. When this happens, the most likely error to occur is a type error involving . We should instead look if the rhs expression is a method chain and look at all the chained call's type to find where is introduced. Given Ideally the output would be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I'd like to try working on this :) claim
Change:
name_to_append_suffix_to.push('<'); for (i, &actual_type) in actual_types.iter().enumerate() { <ins> let actual_type = normalize_associated_type(cx.tcx(), &actual_type); </ins> // Add actual type name to <...> clause of function name let actual_type_name = compute_debuginfo_type_name(cx, actual_type,

Discussion:
When trying to compile nphysics on a nightly created on or after , the compiler errors. Before this date it is fine. Example code: Presumably was that broke things, as it's a commit on that day that touches trans. On Windows 64 bit GNU this is the output:
cc
You sure it's that innocent commit and not, you know, my changes to debuginfo, for MIR? Specifically, is gone, that could cause problems.
I can't reproduce on master (just rebased one of my branches containing unrelated changes, so I had a compiler to check with). EDIT: Still no reproduction, even after .
Ok so I was misinterpreting which crate was being compiled. nphysics compiles fine, but , which uses nphysics, doesn't. I'm trying to narrow down the code now.
Here's some of the rust log that I got when compiling on debug builds:
That's not really helpful, sadly, nightly doesn't use yet, so there's no output.
This bug is not in beta, correct?
I'm afraid that I can't test that as I'm using s.
Can you check the test from instead? Particularly interested about the nightlies you had issues with.
Sure, unfortunately that test case works fine for both pre and post-.
Ah, beats me then.
I'll try and find which part of my code hits the error.
So I did some digging and I was wrong again, it turns out it is the nphysics crate. This is a minimal test case:
It depends on the crate, but it's not the crate itself, and that testcase is still large in terms of how much it needs to monomorphize.
True, sorry but I am not knowledgeable at all in rustc or nphysics, so it's the best I can do :/
triage: P-high
Still need a good regression test.
triage: P-low
I'm going to go ahead and close this. It's somewhat unlikely we'll hit this again (at least, we haven't obviously done so in the past 3ish years), and coming up with a good test case when the current case is all of nphysics is likely to be quite hard.
Change:
+-------------------------------------+------------+------------+------------+------------+ | File                                | Documented | Percentage |   Examples | Percentage | +-------------------------------------+------------+------------+------------+------------+ <del> | ...est/rustdoc-ui/coverage/enums.rs |          6 |      75.0% |          0 |       0.0% | </del> <ins> | ...est/rustdoc-ui/coverage/enums.rs |          6 |      66.7% |          0 |       0.0% | </ins> +-------------------------------------+------------+------------+------------+------------+ <del> | Total                               |          6 |      75.0% |          0 |       0.0% | </del> <ins> | Total                               |          6 |      66.7% |          0 |       0.0% | </ins> +-------------------------------------+------------+------------+------------+------------+

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
const NANOS_PER_MICRO: u32 = 1_000; const MILLIS_PER_SEC: u64 = 1_000; const MICROS_PER_SEC: u64 = 1_000_000; <ins> const MAX_NANOS_F64: f64 = ((u64::MAX as u128)*(NANOS_PER_SEC as u128)) as f64; </ins> /// A `Duration` type to represent a span of time, typically used for system /// timeouts.

Discussion:
Attempting to compile this: will give this error: I was thinking that a clearer error could be something along the lines of: and give this hint:
This should be straightforward to add a help message for. This error message is emitted here: The immediately afterwards is responsible for giving suggestions relevant to the particular type. You'd need to add a new case for () and emit an appropriate message (there are examples for other types in the expression), if the field is numeric. If anyone'd like to tackle this, just post a reply here — I can give more details as needed (but it's always useful to try working things out yourself first, to get a feel for where to find things).
I don't have any experience with Rustc's codebase, but I would be willing to give it a try.
great! If you need any help, you can post a comment here, or ask on or #rustc. Once you add the help message, you'll need to add a test for it (there are plenty of examples in — you can run to test and produce the output).

Do you have some more info? Is this something users experience? Or is it mostly custom drivers running into problems?
When implementing myself I accidentally tried to parse a different file type. This returned an error from , but the error was never printed to the user, instead it said ...`.
It's possible if an rlib/dylib gets corrupt, because then it won't say the file is corrupt. Yes
Change:
use rustc_ast as ast; use rustc_codegen_ssa::traits::CodegenBackend; <ins> use rustc_codegen_ssa::CodegenResults; </ins> use rustc_data_structures::svh::Svh; use rustc_data_structures::sync::{Lrc, OnceCell, WorkerLocal}; use rustc_hir::def_id::LOCAL_CRATE;

Discussion:
This allows giving a better error when attempting to use the original source file with -Zlink-only rather than crashing and allows rejecting rlink files produced by a different rustc version.
To clarify: here's what I thought you had to do: But that gives an inscrutable error like this: The correct way to invoke is actually this If the file has a header, the code that reads it can check for that header. If it's not present (e.g. because somebody passed a file by mistake) then it can give a nice error message like "this doesn't look like a .rlink file".
I tried to look at this. is a struct that is serialized to files using the machinery. I tried to create a wrapper struct that would serialize and deserialize a header to provide nicer messages, but it's not really easy to provide a custom message if decoding of the header fails currently, since you removed the s from methods :sweat_smile: I see several solutions to this: 1) Catch panic that could be caused by invalid decoding of the header and provide a nicer message in that case (seems dubious). 2) Implement serialization and deserialization of the header using manual byte writes/reads, going around the traits. 3) Return sto methods (probably not worth it because of this). What do you suggest, solution 2)?
The crate metadata encodes and decodes the header separately from the contents. For crate metadata the header is of the form "rust" + 32bit be version number (currently 5 I believe) + 32bit offset of the crate root + rustc version string. During decoding the header is checked for "rust", the right version number and then the right rustc version. Only after that is a created to decode the contents. The rlink header could work the same way except omitting the offset of the crate root and using say "rsld" (rust ld) or "rustlink" as start instead of "rust" like the crate metadata.
Thanks for the hint. I checked rmeta decoding and it basically decodes the magic header byte slice with , which should be easy, but then it uses for decoding the rustc version, which will panic if the version is missing. So with this approach we could have a nice error if header magic is missing, nice error if rust version is wrong, but weird error if rust version if missing.

That is basically the same that we get for parsing, so I suppose that's ok?
Yeah, the header magic is supposed to be changed every time the rustc version needs to be decoded in a different way. IMO it is ok.
Change:
let hir_id = self.cx.tcx.hir().as_local_hir_id(local); if !self.cx.tcx.privacy_access_levels(LOCAL_CRATE).is_exported(hir_id) <ins> && (item.visibility == Visibility::Public) </ins> && !self.cx.render_options.document_private { let item_name = item.name.as_deref().unwrap_or("<unknown>");

Discussion:
With merged (current nightly, e.g. ) , the following code now produces a warning: This triggers : But rustdoc never actually generates any links to , because it wasn't run with . In my opinion it shouldn't emit warning in this case, because documenting the internals can be very useful to contributors or even future me when is used. There has already been some discussion at the end of , which is where I asked first about whether this change was intentional.
modify labels: T-rustdoc A-intra-doc-links
Assuming the consensus is that rustdoc shouldn't warn in this case, would an additional check against the 's visibility be correct? Like: That certainly gets rid of the warning in my case, but I'm unsure about the other variants of and all the other kinds of things can refer to.
That looks reasonable to me. Could you make a PR with that change and a few test cases?
Wouldn't the check like I changed it then only catch cases like this: But that already triggers anyway:
the link is entirely separate from the type of the field. You could have in which case there would be no error but the warning should still be generated.
Ah, yes of course, thanks for pointing that out :) I'll open a PR then.
Change:
} if tcx.sess.opts.unstable_opts.drop_tracking_mir && let DefKind::Generator = tcx.def_kind(closure_def_id) <ins> && let Some(generator_layout) = tcx.mir_generator_witnesses(closure_def_id) </ins> { <del> let generator_layout = tcx.mir_generator_witnesses(closure_def_id); </del> for interior_ty in &generator_layout.field_tys { label_match(interior_ty.ty, interior_ty.source_info.span); }

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