jiebi/CodeConvo huggingface dataset:
Change:
/// The size of a type in bytes. /// <del> /// This is the exact number of bytes in memory taken up by a /// value of the given type. In other words, a memset of this size /// would *exactly* overwrite a value. When laid out in vectors /// and structures there may be additional padding between /// elements. </del> <ins> /// More specifically, this is the offset in bytes between successive /// items of the same type, including alignment padding. </ins> pub fn size_of<T>() -> usize; /// Moves a value to an uninitialized memory location.

Discussion:
Discussion of with the lang team led to inspection of the documentation for and () just says "returns the size of a type in bytes." Understanding what this means (and deciding whether it is true or not) depends on how one interprets the word "size" in that sentence. () is worse. Why? Because it adds the additional paragraph: This is much more specific, but the specifics are wrong in terms of that the implementation does. The quoted text is describing the notion of "size" as . But Rust's implementation of ends up eventually calling out to LLVM's , which: At this point we cannot change the name nor the behavior of -- which is fine, since as I understand it, the behavior of basically matches that of in the C/C++ language family. But we should: the documentation for , to make it clear what its behavior is (for this, we might as well point out that it is behaving like "stride" in Swift's terms) should either fix the documentation for so it no longer outright lies, or replace that single intrinsic with a pair of intrinsics that are analogous to Swift's and . (With respect to , if we do introduce an analogous distinction, we will have to choose a name other than "size" for the quantity that is not forcibly rounded up to a multiple of the alignment. Maybe "length", "fill", or "utilization"...) Neither of the above items are incredibly high priority, since the docs are not currently lying (just vague), and is unstable. But it would probably be good to address at least one of the two, for these reasons: to avoid users making invalid inferences about 's behavior (and thus manually rounding up its results to each type's alignment), and to avoid some well-meaning Rust developer cut-and-pasting the docs over into .
I'd like to take this one if is alright with it.
Change:
} } <del> fn encode_info_for_ty(&mut self, ty: &hir::Ty) { match ty.kind { hir::TyKind::Array(_, ref length) => { let def_id = self.tcx.hir().local_def_id(length.hir_id); self.record(def_id, EncodeContext::encode_info_for_anon_const, def_id); } _ => {} } } </del> fn encode_info_for_expr(&mut self, expr: &hir::Expr) { match expr.kind { hir::ExprKind::Closure(..) => {

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
} } <del> fn encode_info_for_ty(&mut self, ty: &hir::Ty) { match ty.kind { hir::TyKind::Array(_, ref length) => { let def_id = self.tcx.hir().local_def_id(length.hir_id); self.record(def_id, EncodeContext::encode_info_for_anon_const, def_id); } _ => {} } } </del> fn encode_info_for_expr(&mut self, expr: &hir::Expr) { match expr.kind { hir::ExprKind::Closure(..) => {

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Check that projections don't count as constraining type parameters. struct S<T>(T); trait Tr { type Assoc; fn test(); } impl<T: Tr> S<T::Assoc> { //~^ ERROR the type parameter `T` is not constrained fn foo(self, _: T) { T::test(); } } trait Trait1<T> { type Bar; } trait Trait2<'x> { type Foo; } impl<'a,T: Trait2<'a>> Trait1<<T as Trait2<'a>>::Foo> for T { //~^ ERROR the lifetime parameter `'a` is not constrained type Bar = &'a (); } fn main() {} </ins>

Discussion:
You can create an inherent impl where the impl substs are not constrained by the impl signature. If the parameters are constrained by the method signature, you can even get code that usefully runs (otherwise you get "can't resolve" errors): Note that you need to use UFCS notation to avoid (which is an issue with method lookup). RFC447 is silent with regards to this issue, but this allows you to create an impl that is not resolvable by its trait-ref.
cc
Heh, I was just telling in IRC the other day that this case was broken. I agree, the current logic is too simplistic (it's also something I've been writing up in this RFC I keep talking about...). Basically, it currently considers all input/type parameters which appear as constrianed, but it ought to stop at projections. I made this gist, which is a similar example:
To be clear, I don't think that fixing this issue requires an RFC (it's just a bug, I think). I just meant that I was writing up various text that referenced the notion of "constrained type parameters" and tried to give a definition, which is how I realized this problem.
Change:
<ins> error[E0425]: cannot find value `unknown` in this scope --> $DIR/dont-autoderef-ty-with-escaping-var.rs:17:35 | LL |     <i32 as RefFoo<i32>>::ref_foo(unknown); |                                   ^^^^^^^ not found in this scope error[E0277]: the trait bound `for<'a> &'a mut Vec<&'a u32>: Foo<'static, i32>` is not satisfied --> $DIR/dont-autoderef-ty-with-escaping-var.rs:17:35 | LL |     <i32 as RefFoo<i32>>::ref_foo(unknown); |     ----------------------------- ^^^^^^^ the trait `for<'a> Foo<'static, i32>` is not implemented for `&'a mut Vec<&'a u32>` |     | |     required by a bound introduced by this call | note: required for `i32` to implement `RefFoo<i32>` --> $DIR/dont-autoderef-ty-with-escaping-var.rs:9:9 | LL | impl<T> RefFoo<T> for T |         ^^^^^^^^^     ^ LL | where LL |     for<'a> &'a mut Vec<&'a u32>: Foo<'static, T>, |                                   --------------- unsatisfied trait bound introduced here error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0425. For more information about an error, try `rustc --explain E0277`. </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. --<!-- 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
Started crashing with Regression in nightly-2022-05-19 commit[0] 2022-05-17: Auto merge of - jsha:rustdoc-search-refactor, r=GuillaumeGomez commit[1] 2022-05-18: Auto merge of - JohnTitor:rollup-7gdt2aw, r=JohnTitor commit[2] 2022-05-18: Auto merge of - Dylan-DPC:rollup-06u9pqn, r=Dylan-DPC commit[3] 2022-05-18: Auto merge of - Kobzol:pgo-pid-in-profile, r=lqd commit[4] 2022-05-18: Auto merge of - michaelwoerister:path-prefix-fixes-2, r=davidtwco commit[5] 2022-05-18: Auto merge of - nbdd0121:const, r=nagisa commit[6] 2022-05-18: Auto merge of - SparrowLii:let, r=michaelwoerister commit[7] 2022-05-18: Auto merge of - b-naber:transition-to-valtrees-pt1, r=oli-obk
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
Change:
/// `-Zpolonius` values, enabling the borrow checker polonius analysis, and which version: legacy, /// or future prototype. <del> #[derive(Clone, Copy, PartialEq, Hash, Debug)] </del> <ins> #[derive(Clone, Copy, PartialEq, Hash, Debug, Default)] </ins> pub enum Polonius { /// The default value: disabled. <ins> #[default] </ins> Off, /// Legacy version, using datalog and the `polonius-engine` crate. Historical value for `-Zpolonius`.

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
//@ ignore-vxworks no 'sh' //@ ignore-fuchsia no 'sh' <ins> //@ ignore-emscripten No threads //@ only-unix SIGPIPE is a unix feature </ins> use std::process; use std::thread; <del> #[cfg(unix)] </del> fn main() { // Just in case `yes` doesn't check for EPIPE... thread::spawn(|| {

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
obligations); if projected_ty.has_projection_types() { <del> let mut normalizer = AssociatedTypeNormalizer::new(selcx, cause, depth); </del> <ins> let mut normalizer = AssociatedTypeNormalizer::new(selcx, cause, depth+1); </ins> let normalized_ty = normalizer.fold(&projected_ty); debug!("normalize_projection_type: normalized_ty={:?} depth={}",

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
); for (idx, arg) in matched_inputs.iter().enumerate() { let suggestion_text = if let Some(arg) = arg { <del> let arg_span = provided_args[*arg].span; </del> <ins> let arg_span = provided_args[*arg].span.source_callsite(); </ins> let arg_text = source_map.span_to_snippet(arg_span).unwrap(); arg_text } else {

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Caused by this line introduced in I found a similar issue in the past, this pull request fixes it: Unfortunately, this one looks like a spurious failure. It can be reproduced in the playground using nightly 2022-04-18, but when I try it locally using the same nightly version there is no ICE. This is the error message: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this still reproducible? I didn't get the ICE, maybe theres some extra flags needed?
The playground seems to reliably reproduce it. And I can reproduce it sometimes using : But that is not always reliable. Given that the error message is "SourceNotAvailable", I guess this is related to how the toolchain is installed (the rust-src component?). Because at one point I tried the latest nightly with cargo-bisect-rustc and it did not ICE, but some days later I tried the same nightly using the same command and it did ICE. But I would just assume that while there is an in the code this issue is not fixed.
I'm currently using rustc 1.62.0-nightly ( 2022-04-25) and from the 10 times I tried executing the code, all of them generated an ICE.
I think I see this issue too. I also had to go back to 2022-04-18 to be able to compile my code.
I opened a pull request with a one line change that may fix this, but I have no way to reproduce it locally (compiling the example code works fine even without the changes of that pull request). The playground can still reproduce the issue as of nightly 2022-04-29, so we can use it to check if this issue is really fixed after that pull request is merged.
So I accidentally closed this issue by adding the words "may to the pull request description, but fortunately it looks fixed, as you can see thanks to the glacier bot.
Change:
})?) } <ins> fn check_item_well_formed<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { wfcheck::check_item_well_formed(tcx, def_id); } fn check_trait_item_well_formed<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { wfcheck::check_trait_item(tcx, def_id); } fn check_impl_item_well_formed<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { wfcheck::check_impl_item(tcx, def_id); } </ins> pub fn provide(providers: &mut Providers) { *providers = Providers { typeck_item_bodies,

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.
Change:
<ins> // run-rustfix trait O { type M; } trait U<A: O> { const N: A::M; } impl<D> O for D { type M = u8; } impl<C: O> U<C> for u16 { const N: C::M = 4u8; //~ ERROR mismatched types } fn main() {} </ins>

Discussion:
Repro: This caused E0277 "the trait bound is not satisfied" error: The error doesn't make sense because is obviously . It seems the associated const type is evaluated before the generic bounds are , causing this error. Changing both and to makes the error go away. Reproducible on all 3 versions on playground (1.23.0, 1.24.0-beta, 1.25.0-nightly).
This exact issue just occured to and me when trying to use associated constants to create a constant struct in a library with user-provided data (without const fns) (actual use case: ). A minimized examples is this (): Error: The interesting thing is that even though both bounds are specified, the compiler doesn't seem to take them into account. Edit: The issue is not using a trait with an associated type and const as generic bound. Instead the problem is implementing a trait with an associated type and const in general:
I ran into the same problem. It's also in 1.26 stable. Here's a further minimized example (): We can also use the type parameter in the trait rather than the type (): Both code fragments give an error saying that in the blanket impl, Rust cannot figure out that implements and : Note that in both cases, if you remove the constraint on the quantified type , the error about goes away! This is very strange. However, like in , the error message stays. The problem goes away if you declare the type of in to be , rather than some type that is computed potentially based on parameters. I'm not familiar with the compiler internals, but my hypothesis is that associated types and constants depending on a type parameter are not evaluated properly in the constant expression evaluator. In this case, it's associated types that do not reduce well: forces Rust to do some fancy type of computation at compile time in order to type check, but there's a bug in the code for such computations. I feel there are a couple of different issues in the same spirit: In , Rust is trying to check two types against each other, which forces it to simplify the type . This fails. The error message shows that Rust cannot decide that , even though was in the where clause. Same in , where they get a warning (!) about a "constant evaluation error".

In , the same happens but with a consteval that uses a different trait fn.
Copying over my minimal example from as another data point (): Here I've a supertrait to my trait to get rid of the issue but it still can't determine the required trait implementation (of my trait in this case) to make this work.
All of these cases now compile, except for , which has a type error: Current output: The correct code would be The outstanding work would be providing a suggestion explaining what "consider constraining the associated type to " means. This will be hard to do given the different cases that need to be accounted for, for the case above you need to move the constraint to , for example (although that's not needed, just nicer stylistically).
Change:
error: constant evaluation is taking a long time <del> --> $DIR/infinite_loop.rs:6:9 </del> <ins> --> $DIR/infinite_loop.rs:12:9 </ins> | LL | /         while n != 0 { LL | |

Discussion:
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
Regression in nightly-2023-06-02 Regression in cc
Change:
info.missing_lang_items.reserve(n_crates); for &cnum in crates.iter() { <del> info.native_libraries.insert(cnum, tcx.native_libraries(cnum)); </del> <ins> info.native_libraries .insert(cnum, tcx.native_libraries(cnum).iter().map(Into::into).collect()); </ins> info.crate_name.insert(cnum, tcx.crate_name(cnum).to_string()); info.used_crate_source.insert(cnum, tcx.used_crate_source(cnum)); if tcx.is_panic_runtime(cnum) {

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. --I tried this command: I expected to see this happen: An file is generated. Instead, this happened: <!-- 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.