jiebi/CodeConvo huggingface dataset:
Change:
"0x12345678", "0x78563412", "0x1e6a2c48", "[0x78, 0x56, 0x34, 0x12]", "[0x12, 0x34, 0x56, 0x78]", usize_isize_to_xe_bytes_doc!(), usize_isize_from_xe_bytes_doc!() } <del> widening_impl! { isize, i64, 32, signed } </del> } #[cfg(target_pointer_width = "64")]

Discussion:
I had this question on the currently unreleased ; on signed carry (probably applies to substraction too ?); I have this test failing with the current code: Playground: Is the test correct ? A carry did happen in an intermediate calculation, but should the overall calculation report a carry ?
I agree that this is a bug. There's a carry when the calculation is done as unsigned, but this is not the same in signed. Another example: That incorrectly returns .
There's some discussion about that in the tracking issue, starting with
Yeah, it looks like I rehashed the same arguments, that's what I get for reading comments and doc too fast. Still, I think that this is surprising enough that it would be nice to address it somehow.
I agree this is a bug. It looks like it's implementing the signed version using the unsigned one, returning the same carry flag (), but that's incorrect. Here's another demonstration that it needs an update: you be up to making a fix PR, You can use to get assigned to this issue.
I have no bandwidth for making a fix right now. Since this was supposed to be helpers for bigint operations, my first idea was to just remove the signed variants. I have no idea if this would be appropriate. Anyone is welcome to do a proper fix, it shouldn't be too complicated.
A thought: What should do? It feels to me like the carryout from that should perhaps be , since the carry from that is different from the one in , which would imply that it couldn't be anymore. We do have a type that's -1, 0, or 1: . I can't decide if that's clever or horrible. Or should we just delete the signed versions for now?
I think should return , because signed and unsigned operations should give the same results, so should be computed as which gives , then truncated to 8-bits which gives . Then because gives , which can't be represented as an 8-bits signed number, then there is overflow to me. Now for the -1, 0, 1 overflow, I don't think it's necessary because the point of the bit is to indicate if it happened or not. The direction of overflow is indicated by the resulting value. If I am correct, then this raises another question: should intermediate overflow be detected or not ?

for example: gives a result of -128, so the output is the same as the input so no overflow. But if we break down the operations, overflows to 127, and then overflows back to -128. In this case should an overflow occur or not ? Considering my previous example, I personally think it intermediate overflow shouldn't be detected because it would be misleading: it would indicate that the sign of the source operands and the result are different while they are the same. Tho I'd like other's opinion.
I think so. The unsigned versions have clear semantics, but it gets weird with signed values, and as a "bigint helper" I'd be surprised to see one that uses signed digits in the first place.
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] struct Send<T> { i: InnerSend<T>, } type InnerSend<T> = impl Sized; fn constrain<T>() -> InnerSend<T> { () } trait SendMustNotImplDrop {} #[allow(drop_bounds)] impl<T: Drop> SendMustNotImplDrop for T {} impl<T> SendMustNotImplDrop for Send<T> {} fn main() {} </ins>

Discussion:
The full log is available from this link: From the aforementioned link:
Do you have a more concise way of reproducing this? I can't seem to get it to ICE when I run with , no matter if I use , etc.
nvm, should be using ..
This is actually reproducible even with . It seems to only ICE with feature. Command for reproduction: <details<summary<strongBacktrace</strong</summary<p</p</detailsWe don't use feature much, so it should be easy, to make a MRE, I'll try.
I found an MRE. I'll put up a fix in a second.
I found a MRE too :(
+1, I basically reproduced that in the UI test but manually expanding the part of the macro that causes the ICE.
Change:
} else { ast::InlineAsmOperand::InOut { reg, expr, late: false } } <del> } else if p.eat(&token::Ident(sym::inlateout, false)) { </del> <ins> } else if p.eat_keyword(sym::inlateout) { </ins> let reg = parse_reg(&mut p, &mut explicit_reg)?; let expr = p.parse_expr()?; if p.eat(&token::FatArrow) {

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
use crate::compile; use crate::config::TargetSelection; use crate::dist; <ins> use crate::doc::DocumentationFormat; </ins> use crate::flags::Subcommand; use crate::native; use crate::tool::{self, SourceType, Tool};

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:
use rustc_codegen_ssa::traits::{CodegenBackend, ExtraBackendMethods, ModuleBufferMethods, ThinBufferMethods, WriteBackendMethods}; use rustc_data_structures::fx::FxHashMap; use rustc_errors::{ErrorReported, Handler}; <ins> use rustc_metadata::EncodedMetadata; </ins> use rustc_middle::dep_graph::{WorkProduct, WorkProductId}; <del> use rustc_middle::middle::cstore::EncodedMetadata; </del> use rustc_middle::ty::TyCtxt; use rustc_session::config::{Lto, OptLevel, OutputFilenames}; use rustc_session::Session;

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
} } <ins> impl<Sized? T> Deref<T> for Box<T> { fn deref(&self) -> &T { &**self } } impl<Sized? T> DerefMut<T> for Box<T> { fn deref_mut(&mut self) -> &mut T { &mut **self } } </ins> #[cfg(test)] mod test { #[test]

Discussion:
As titled. Currently Box does not implement Deref: But Box should be able to implement Deref.
(Tagged E-easy in the hope that it's as simple as adding the impls gives in the issue. There is the chance that there is some compiler peculiarities that make this not-easy.)
has kindly volunteered to mentor; catch him here or as on IRC.
Can I have a go at this? Looks easy enough...
it's already been done/attempted in . :smile:
Oh well, never mind, I must've overlooked the cross-ref...
This issue seems resolved due to close and merge.
unfortunately it wasn't merged.
Change:
// given the type `Option<MyStruct<u8>>`, we will check // `Option<MyStruct<u8>>`, `MyStruct<u8>`, and `u8`. // For each type, we perform a well-formed check, and see if we get <del> // an erorr that matches our expected predicate. We keep save </del> <ins> // an error that matches our expected predicate. We save </ins> // the `ObligationCause` corresponding to the *innermost* type, // which is the most specific type that we can point to. // In general, the different components of an `hir::Ty` may have <del> // completely differentr spans due to macro invocations. Pointing </del> <ins> // completely different spans due to macro invocations. Pointing </ins> // to the most accurate part of the type can be the difference // between a useless span (e.g. the macro invocation site) <del> // and a useful span (e.g. a user-provided type passed in to the macro). </del> <ins> // and a useful span (e.g. a user-provided type passed into the macro). </ins> // // This approach is quite inefficient - we redo a lot of work done // by the normal WF checker. However, this code is run at most once // per reported error - it will have no impact when compilation succeeds, <del> // and should only have an impact if a very large number of errors are // displaydd to the user. </del> <ins> // and should only have an impact if a very large number of errors is // displayed to the user. </ins> struct HirWfCheck<'tcx> { tcx: TyCtxt<'tcx>, predicate: ty::Predicate<'tcx>,

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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly
Change:
}; ConstValue::from_machine_usize(n, &tcx) } <del> sym::type_id => ConstValue::from_u64(tcx.type_id_hash(tp_ty)), </del> <ins> sym::type_id => { if tp_ty.needs_subst() { throw_inval!(TooGeneric); } ConstValue::from_u64(tcx.type_id_hash(tp_ty)) } </ins> sym::variant_count => { if let ty::Adt(ref adt, _) = tp_ty.kind { ConstValue::from_machine_usize(adt.variants.len() as u64, &tcx)

Discussion:
I tried this code: I expected the code to run without errors Instead, the assertion failed. Compiler version: 1.46.0-nightly (2020-07-01 )
Seems something wrong with the intrinsics evaluation.
I think the issue is that is in place when we try to hash . I am not very familiar with the code here but I think this might be evaluated before monomorphization which causes this issue.
Another example showing this is pre-monomorphization: rustc happily compiles this, but I would expect something like .
I was trying to do something somewhat similar with const type_id when I filed . There seem to be some inconsistencies in what combinations of generics and patterns are allowed, which might be contributing to the problem.
I have no idea what is going on, but it certainly looks odd... Cc
needs to monomorphize the type before evaluating it I'd guess (an assert checking for would make sense there, too I'd think).
I wonder if instead of we should more explicitly check for "type or const params", but I think it's mostly about aesthetics thanks to miri working with lifetime-erased types. You said "assert" but I think the type is already monomorphized and what we need to do is return if it's not monomorphic. Same for , actually - any reflection that doesn't rely on will have this problem.
oh right, this may be an evaluation happening too early, so is totally reasonable to emit here. I'm always wary of emitting .
Doesn't that mean that the code samples above will be forbidden?
No, just evaluating the consts early will fail. Once everything is monomorphized it will work.
I have an attempt here: It prevents OP's snippet from compiling:
hmm... maybe const prop is interfering here. Can you try running the same build with and ?
Ah, so this is a different issue. It's the same issue (even if a different symptom) of running
Patterns need to be monomorphic, you can never have a pattern that depends on generic parameters. We may lift this restriction in the future, but it's a separate issue and needs a language RFC afaik
in stable and gives in nightly. We will need a better diagnostics for the TooGeneric error.
works on stable, so the old diagnostic was wrong. It's specifically associated constants that depend on generic parameters.

so is the approach of returning all we need to do here? If so would you be happy to open your branch as a PR so we could look at adding some ui tests and whatnot?
The thing I worried is that the error isn't very helpful. Maybe fixing that diagnostics should be a separate PR?
Yea, cleaning up the diagnostics can be done after fixing the bug
Change:
LifetimeRes::Fresh { param, binder: _ } => { debug_assert_eq!(lifetime.ident.name, kw::UnderscoreLifetime); <del> if let Some(old_def_id) = self.opt_local_def_id(param) && remapping.get(&old_def_id).is_none() { </del> <ins> if let Some(old_def_id) = self.orig_opt_local_def_id(param) && remapping.get(&old_def_id).is_none() { </ins> let node_id = self.next_node_id(); let new_def_id = self.create_def(

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
<ins> fn main() { let foo = 1; { let bar = 2; let test_func = |x| x > 3; } if bar == 2 { //~ ERROR cannot find value println!("yes"); } test_func(1); //~ ERROR cannot find function } </ins>

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
<ins> // ignore-tidy-linelength // regression test for #26376 trait Foo { fn foo(&self) -> [u8]; } fn foo(f: Option<&dyn Foo>) { if let Some(f) = f { let _ = f.foo(); //~^ ERROR cannot move a value of type [u8]: the size of [u8] cannot be statically determined } } fn main() { foo(None) } </ins>

Discussion:
This does generate code that calls in the vtable, but is not particularly useful. cc
Still a problem?
It's still true, but I'm not especially worried about it.
Isn't it a bug that you can declare such a trait at all? There's no way to implement it, right?
This code is now rejected with:
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash // tests the diagnostic output of type mismatches for types that have const generics arguments. use std::marker::PhantomData; struct A<'a, T, const X: u32, const Y: u32> { data: PhantomData<&'a T> } fn a<'a, 'b>() { let _: A<'a, u32, {2u32}, {3u32}> = A::<'a, u32, {4u32}, {3u32}> { data: PhantomData }; //~^ ERROR mismatched types let _: A<'a, u16, {2u32}, {3u32}> = A::<'b, u32, {2u32}, {3u32}> { data: PhantomData }; //~^ ERROR mismatched types } pub fn main() {} </ins>

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
(self.data[word] & mask) != 0 } <ins> /// Returns true if the bit has changed. </ins> pub fn insert(&mut self, bit: usize) -> bool { let (word, mask) = word_mask(bit); let data = &mut self.data[word]; let value = *data; <del> *data = value | mask; (value | mask) != value </del> <ins> let new_value = value | mask; *data = new_value; new_value != value </ins> } pub fn insert_all(&mut self, all: &BitVector) -> bool {

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
#[inline(always)] fn local_raw_waker<W: LocalWake + 'static>(waker: Rc<W>) -> RawWaker { // Increment the reference count of the Rc to clone it. <ins> // // Refer to the comment on raw_waker's clone_waker regarding why this is // always inline. #[inline(always)] </ins> unsafe fn clone_waker<W: LocalWake + 'static>(waker: *const ()) -> RawWaker { unsafe { Rc::increment_strong_count(waker as *const W) }; RawWaker::new(

Discussion:
I would expect this to run to completion: On stable, it does: But not on current nightly: Interestingly, it works ok without cargo: The cargo project isn't special though: OS: macOS 13.6.3
cc I guess?
The internal function uses const promotion for the vtable in two places, once at initial construction and another when cloning. Maybe that results in two differently-addressed vtables.
I gave this a shot in . But without a language feature for statics with type parameters, we are not seeing a reliable way to restore 's functionality. Let's consider reverting . Having be a handful of CPU instructions faster but way more often wrong is not useful.
Change:
span: Span, ) { let tcx = infcx.tcx; <del> let impl1_predicates: Vec<_> = traits::elaborate_predicates( </del> <ins> let instantiated = tcx.predicates_of(impl1_def_id).instantiate(tcx, impl1_substs); let impl1_predicates: Vec<_> = traits::elaborate_predicates_with_span( </ins> tcx, <del> tcx.predicates_of(impl1_def_id).instantiate(tcx, impl1_substs).predicates.into_iter(), </del> <ins> std::iter::zip( instantiated.predicates, // Don't drop predicates (unsound!) because `spans` is too short instantiated.spans.into_iter().chain(std::iter::repeat(span)), ), </ins> ) <del> .map(|obligation| obligation.predicate) </del> <ins> .map(|obligation| (obligation.predicate, obligation.cause.span)) </ins> .collect(); let mut impl2_predicates = if impl2_node.is_from_trait() {

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
DeclUnsafeMethod, #[diag(lint_builtin_impl_unsafe_method)] ImplUnsafeMethod, <ins> #[diag(lint_builtin_global_asm)] #[note(lint_builtin_global_macro_unsafety)] GlobalAsm, </ins> } #[derive(LintDiagnostic)]

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
} } clean::ResolvedPath { typarams: Some(ref v), .. } if !v.is_empty() => { <del> if f.alternate() { write!(f, "&{}{}", lt, m)?; } else { write!(f, "&amp;{}{}", lt, m)?; } write!(f, "(")?; </del> <ins> write!(f, "{}{}{}(", amp, lt, m)?; </ins> fmt_type(&ty, f, use_absolute)?; write!(f, ")") } <ins> clean::Generic(..) => { primitive_link(f, PrimitiveType::Reference, &format!("{}{}{}", amp, lt, m))?; fmt_type(&ty, f, use_absolute) } </ins> _ => { <del> if f.alternate() { write!(f, "&{}{}", lt, m)?; fmt_type(&ty, f, use_absolute) } else { write!(f, "&amp;{}{}", lt, m)?; fmt_type(&ty, f, use_absolute) } </del> <ins> write!(f, "{}{}{}", amp, lt, m)?; fmt_type(&ty, f, use_absolute) </ins> } } }

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.