jiebi/CodeConvo huggingface dataset:
Change:
pub fn check_struct(ccx: @CrateCtxt, id: ast::NodeId, span: Span) { let tcx = ccx.tcx; <del> // Check that the class is instantiable </del> <ins> // Check that the struct is representable check_representable(tcx, span, id, "struct"); // Check that the struct is instantiable </ins> check_instantiable(tcx, span, id); if ty::lookup_simd(tcx, local_def(id)) {

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
value: &Lvalue<'tcx>, item_ty: Ty<'tcx>) { for scope in self.scopes.iter_mut().rev() { <ins> // See the comment in schedule_drop above. The primary difference is that we invalidate // the unwind blocks unconditionally. That’s because the box free may be considered // outer-most cleanup within the scope. scope.invalidate_cache(true); </ins> if scope.extent == extent { assert!(scope.free.is_none(), "scope already has a scheduled free!"); <del> // We also must invalidate the caches in the scope for which the free is scheduled // because the drops must branch into the free we schedule here. scope.invalidate_cache(); </del> scope.needs_cleanup = true; scope.free = Some(FreeData { span: span,

Discussion:
This was discovered in database connection pooling where connections were not returned to the pool properly, and reported under Unfortunately I do not have example code small enough to share at this point. I narrowed down the rust-nightly version that introduced the bug to nightly-2016-08-03-x86_64-unknown-linux-gnu
when compiled with RUSTFLAGS="-Zorbit=off" the issue does not appear, so yes it is the MIR as suspected.
The compiler not running drop glue is not considered unsafe behaviour (i.e. it is allowed to happen), but it is still weird this happens. cc could be your drop elaboration not catching this () case? Something that we could run without having postgresql installed would be ideal test case, even if it depended on other crates for now.
Minimal reproduction:
More minimal: Removing either of early s in the function makes the issue go away. Seems like a scoping issue.
regression-from-stable-to-nightly (for a two more days at least).
Yeah I jumped the gun on the tag, but the beta is building right now.
I saw your commit -- I feel like the extent should be unique for the cleanup scope. That is, we should push a given extent only once -- but perhaps I am wrong about this? It'd be good to add an assertion (or warning) for when we push cleanup scopes with the same extent more than once so we can see what it happens.
Ah, but reading IRC chatter I see that the problem is that the extent of the "outermost scope" changed and thus the helper is out of date? That seems pretty plausible.
As pointed out on the IRC the commit linked above is a shot in the dark and is not a fix.
Change:
x = word_cfg("test"); x |= Cfg::True; <del> assert_eq!(x, Cfg::True); </del> <ins> assert_eq!(x, word_cfg("test")); </ins> x = word_cfg("test2"); x |= Cfg::False;

Discussion:
Context: CC
Thanks for opening this issue! Someone from the rustdoc team will try to get back to it whenever possible.
It doesn't look too difficult. I'm going to try to make a PR for it myself, and I'll update here with or without progress.
Even better! :smile: I'll assign you to the issue in the meantime then.
Change:
fn main() { test(); } <ins> extern "Rust" { fn bar() -> Pointer<_>; //~^ ERROR: the placeholder `_` is not allowed within types } </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. -- (not minimized yet) searched nightlies: from nightly-2024-01-11 to nightly-2024-01-13 regressed nightly: nightly-2024-01-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
label -E-needs-mcve +S-has-mcve +F-impltraitinassoctype +requires-nightly
Change:
fn main() { <del> let _ = fix(|_: &dyn Fn()| {}); </del> <ins> let _ = fix(|_: &dyn Fn()| {}); </ins> } fn fix<F: Fn(G), G: Fn()>(f: F) -> impl Fn() { <del> move || f(fix(&f)) //~^ ERROR mismatched types </del> <ins> move || f(fix(&f)) //~^ ERROR concrete type differs from previous defining opaque type use </ins> }

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
dependencies = [ "annotate-snippets", "bytecount", <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.8.0", </ins> "derive-new", "diff", "dirs",

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.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this:
Change:
in its arguments or return type", name).into(), ObjectSafetyViolation::Method(name, MethodViolationCode::Generic) => format!("method `{}` has generic type parameters", name).into(), <ins> ObjectSafetyViolation::AssociatedConst(name) => format!("the trait cannot contain associated consts like `{}`", name).into(), </ins> } } }

Discussion:
The following code compiles: Furthermore, adding the line to causes an ICE:
I think the code should be legal to compile. It's impossible to get the value of from a variable (there's no such thing as where is a binding of type ).
Well it shouldn't compile
I don't know if this can lead to unsoundness or not. Correct me.
says no
Update on this, the example in the original post compiles today. But this ICEs: AFAICT there are two options here: consts are not object safe, just like associated (static) functions. consts must all be specified, just like associated types. I think its sensible to start with the first. The second makes more sense in the context of a world with const params, but the first can be extended to the second. It might also make sense some day to allow clauses on associated consts just like methods (and on associated types, for that matter, which connects in some degree with the ATC RFC).
Can't associated consts be part of the vtable/fat pointers?
Associated consts are inlined at compiletime, they can't have a value which is determined at runtime. This is a hard requirement for making things like const fn and const generics work. Associated statics could be object safe if they existed.
I think that having to write: instead of just: or is a pain. The value is determined at compile-time, but I am talking about being able to access that value at run-time via dynamic dispatch.
The value is not determined at compile time for the virtually dispatched type (the trait object type). What you want is the fields in traits RFC.
I did not say otherwise (the value is only determined at compile-time for the types that implement , not for itself or trait objects). What I did say is that currently there is no way to access this value at run-time without in my opinion unnecessary boilerplate but there should be one.
Maybe the problem is that traits support associated consts, and associated consts are values, but traits do not support associated values (yet).
Will they be object-safe in the future? I mean if "fn foo() -u8 where Self: Sized;" is already safe why are consts not?
Change:
) -> GetSafeTransmuteErrorAndReason { use rustc_transmute::Answer; <ins> // We don't assemble a transmutability candidate for types that are generic // and we should have ambiguity for types that still have non-region infer. if obligation.predicate.has_non_region_param() || obligation.has_non_region_infer() { return GetSafeTransmuteErrorAndReason::Default; } </ins> // Erase regions because layout code doesn't particularly care about regions. let trait_ref = self.tcx.erase_regions(self.tcx.instantiate_bound_regions_with_erased(trait_ref));

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
pub fn translate(&self) -> Result<String, Option<String>> { match *self { Substitution::Format(ref fmt) => fmt.translate(), <del> Substitution::Escape => Err(None), </del> <ins> Substitution::Escape(_) => Err(None), </ins> } } }

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2021-01-01 to nightly-2021-12-24 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The regression happened in . cc
label regression-from-stable-to-stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I've been taking a look at this. It's pretty interesting. I'm not entirely sure I'll be able to work it out, but I figure I may as well assign myself for the time being while I attempt to solve it.
Another test case:
The problem seems to reside within the crate , in the files and . The function in has a macro, , which is in charge of looking for foreign substitutions - that is, someone using printf or shell style formatting rather than Rust's style. It's a macro so it can be generic over the two types of substitution. The first time this macro is called, for printf substitutions, it finds two (I think "%%" and "%", though I'm not sure it's exactly that). The code that actually detects the substitutions is in . When parsing the substitution, in the function , it is somehow finding that the second substitution has a boundary in the middle of the character. I'm not sure exactly how yet. This gets turned into a span in . The span is malformed, as it splits a character in two, so the second the code tries to use it for anything it trips an assertion and causes this ICE. The remaining problem is figuring out what's going wrong in . This sort of string manipulation is not my forte. I'll probably take another few cracks at it though.
Something is broken about . This change makes the ICE go away (but probably breaks other things):
When returns here: it seems like we should increment by , but we actually only increment it by 2:
yes, I get the exact same error. . The error disappears if you add a new line after the , so maybe your text editor did that automatically.

That was it, thanks. I'm going to unassign myself from this. I do hope my exploration ends up being helpful to whoever fixes it though. if you want to fix this yourself, you certainly seem further along than I was, though you shouldn't feel any pressure to do so if you don't want to.
I put up a PR for a
I opened a new issue for your bug, because it's not exactly the same as this one.
Change:
/// /// This `struct` is created by the [`repeat_n()`] function. /// See its documentation for more. <del> #[derive(Clone, Debug)] </del> #[stable(feature = "iter_repeat_n", since = "1.82.0")] pub struct RepeatN<A> { count: usize, <del> // Invariant: has been dropped iff count == 0. element: ManuallyDrop<A>, </del> <ins> // Invariant: uninit iff count == 0. element: MaybeUninit<A>, </ins> } impl<A> RepeatN<A> { <ins> /// Returns the element if it hasn't been dropped already. fn element_ref(&self) -> Option<&A> { if self.count > 0 { // SAFETY: The count is non-zero, so it must be initialized. Some(unsafe { self.element.assume_init_ref() }) } else { None } } </ins> /// If we haven't already dropped the element, return it in an option. /// /// Clears the count so it won't be dropped again later.

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. --This is technically different from as there's no UAF. However, using with has undefined behavior if you use the last/original element after moving the iterator, since the field has noalias properties. <details<summaryMiri Backtrace</summary<p</p</detailsWrapping the element using (or once we have that) should make this sound.
See also:
The minimal example is actually this: Because eagerly calls drop for . This basically boils down to Which is indeed I quite strongly think that this is a bug in miri and/or ( should use inside of itself probably?). That being said this is not yet decided (again, see the UCG issue) :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Yeah, it should -- someone just has to implement first. ;) See
I tweaked the title because while there is an experimental Miri flag to make Unique magical, codegen only has special treatment for Box.

<!-- 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. --currently unconditionally derives . However, it will also drop its inner object if is 0, which can cause a UAF if it's cloned afterwards. Running the above program segfaults: Edit: Made the segfault quicker/more reliable.
same issue with its implementation
cc I think you implemented this. ^^
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<del> error: cannot mutate statics in the initializer of another static </del> <ins> error[E0080]: could not evaluate static initializer </ins> --> $DIR/write-to-static-mut-in-static.rs:14:33 | LL | pub static mut B: () = unsafe { A = 1; }; <del> |                                 ^^^^^ </del> <ins> |                                 ^^^^^ tried to modify a static's initial value from another static's initializer </ins> <del> error: cannot mutate statics in the initializer of another static </del> <ins> error[E0391]: cycle detected when const-evaluating `C` </ins> --> $DIR/write-to-static-mut-in-static.rs:17:34 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; |                                  ^^^^^ <ins> | note: ...which requires const-evaluating `C`... --> $DIR/write-to-static-mut-in-static.rs:17:1 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: ...which again requires const-evaluating `C`, completing the cycle note: cycle used when const-evaluating + checking `C` --> $DIR/write-to-static-mut-in-static.rs:17:1 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: aborting due to 2 previous errors <ins> Some errors occurred: E0080, E0391. For more information about an error, try `rustc --explain E0080`. </ins>

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
} } <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> impl<'a> FusedIterator for Ancestors<'a> {} ////////////////////////////////////////////////////////////////////////////////

Discussion:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc
Change:
<ins> -include ../../run-make-fulldeps/tools.mk # only-x86_64-unknown-linux-musl # How to manually run this # $ ./x.py test --target x86_64-unknown-linux-musl src/test/run-make/static-pie all: $(RUSTC) --target $(TARGET) -C target-feature=+crt-static test-aslr.rs # Check that no dynamic interpreter is set ! readelf -l $(call RUN_BINFILE,test-aslr) | $(CGREP) INTERP # Check that we have a dynamic executable readelf -l $(call RUN_BINFILE,test-aslr) | $(CGREP) DYNAMIC # Check for address space layout randomization $(call RUN,test-aslr) --test-aslr </ins>

Discussion:
With musl we can generate static binaries just fine. But without much work we can even generate a static position independent executable, which would enable Address Space Layout Randomization for free. For this to work, we need: rustc: gcc: remove any has or replace musl with is a program printing all the AUX vectors, which also contains the entry address of the program. As you can see it changes with every start of the program.
If there will be no native support, at least ship along with and add some possibility to change the startup file.
something like:
The workaround may be similar to what I recently did to statically link to bionic libc () - produce a with and then link manually. ( has nice defaults, but is pretty inflexible when you need to do something different with linking, modulo custom target specifications.)
Hmm, I don't want a workaround. I rather want a secure static binary with ASLR by default.
Change:
let host = compiler.host; let src = builder.sysroot(compiler); <del> // Copy rustc/rustdoc binaries </del> <ins> // Copy rustc binary </ins> t!(fs::create_dir_all(image.join("bin"))); builder.cp_r(&src.join("bin"), &image.join("bin")); <ins> // If enabled, copy rustdoc binary </ins> if builder .config .tools

Discussion:
In a fresh install of 1.72.0 there are some files: The same thing happens with 1.71.1.
Performed a test on 1.72.0 and was able to reproduce the problem. With HEAD: , it is no longer present(most probably fixed on the cargo side since it doesn't have anything to do with bootstrapping). If you encounter the problem again, please feel free to re-open the issue.
I'm still hitting this with 1.73.0.
Perhaps it's related to my setting. I'll do more experiments tomorrow and report back...
Still happens with 1.74.0. The terminal output of (I've removed the lines):
Would be nice if you can share your Last time I tried I couldn't reproduce it.
I think I see the same with Rust 1.76:
Are you building multiple targets?
No. I just set following in : and .
should handle this problem.
Change:
[] fn impl_defaultness: ImplDefaultness(DefId) -> hir::Defaultness, <ins> [] fn check_item_well_formed: CheckItemWellFormed(DefId) -> (), [] fn check_trait_item_well_formed: CheckTraitItemWellFormed(DefId) -> (), [] fn check_impl_item_well_formed: CheckImplItemWellFormed(DefId) -> (), </ins> // The DefIds of all non-generic functions and statics in the given crate // that can be reached from outside the crate. //

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.