jiebi/CodeConvo huggingface dataset:
Change:
impl<'tcx> GenericArg<'tcx> { #[inline] pub fn unpack(self) -> GenericArgKind<'tcx> { <del> let ptr = self.ptr.get(); </del> <ins> let ptr = unsafe { self.ptr.map_addr(|addr| NonZeroUsize::new_unchecked(addr.get() & !TAG_MASK)) }; </ins> // SAFETY: use of `Interned::new_unchecked` here is ok because these // pointers were originally created from `Interned` types in `pack()`, // and this is just going in the other direction. unsafe { <del> match ptr & TAG_MASK { </del> <ins> match self.ptr.addr().get() & TAG_MASK { </ins> REGION_TAG => GenericArgKind::Lifetime(ty::Region(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const ty::RegionKind<'tcx>), </del> <ins> ptr.cast::<ty::RegionKind<'tcx>>().as_ref(), </ins> ))), TYPE_TAG => GenericArgKind::Type(Ty(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::TyKind<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::TyKind<'tcx>>>().as_ref(), </ins> ))), CONST_TAG => GenericArgKind::Const(ty::Const(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::ConstData<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::ConstData<'tcx>>>().as_ref(), </ins> ))), _ => intrinsics::unreachable(), }

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)
Change:
<del> Subproject commit a6f4c1bb07d58df5956d2c49be68547143f77b18 </del> <ins> Subproject commit a56b846ec7c96d8dc86418819baee40d70c92974 </ins>

Discussion:
On current num-integer master (commit ), rustc nightly and beta both crash when targeting . Stable is fine. (The inline attribute warning is irrelevant to success/failure, but I'll clean that up separately.) cc rust-num/num-integer
<details<summaryGDB backtrace of the SIGSEGV thread on nightly:</summary</details
Thanks Minimal reproducible test case:
triage: P-high for now. (but this is a Tier-2 target, so it may get downgraded to P-medium after a few weeks. We will see.)
cc -- the versions correspond to the LLVM change for emscripten.
This looks like an error in the LLVM verifier, so there is something wrong with the generated LLVM IR. I think we can rule out a bug in the WebAssembly LLVM backend.
Sorry I'm not sure where this would be coming from either.. It's likely due to the upgrade of LLVM for the emscripten target for sure though
Hello, Is there an ETA for the fix? Or maybe someone more familiar with the issue could guide me on where/how this can be fixed, so I can try on my own if it's not part of the roadmap yet?
This is on my backlog of things to look into, but I don't know when I will be able to get to it. I don't know of anyone else planning to look into it.
It looks like this affects as well:
tested the minimum test case (above) on wasm32-unknown-emscripten using stable (1.40.0 2019-12-16) and nightly (1.42.0 - 2020-01-01) with the same result: Called function must be a pointer! call addrspace() void &lt;badref(i8* %40), !dbg !52 in function ZN4core4iter5range116implu20u20AGT$9nextback17h9348d20e8f4fe0bcE LLVM ERROR: Broken function found, compilation aborted!
I started looking into this and I can successfully reproduce the crash. On some runs I get additional errors where the junk string is nondeterministic. Sometimes I also get the message . Clearly there is a memory corruption issue. Is there a way to build rustc and its LLVM with AddressSanitizer enabled?

It looks like this is a use-after-free when LLVM is built in release mode. It is caught earlier by an assertion with a debug build of LLVM, and from the backtrace there it looks like there is indeed a previously-unknown issue with the Emscripten exception lowering pass. We are investigating further now.
Fix in LLVM incoming: Once it merges upstream, I will handle getting it merged to Rust's LLVM fork and from there to rustc.
Should be fixed by
Were you able to verify that? I can still reproduce it with .
No, I just checked that the patch had landed. Reopening.
I thought it had been fixed because the regression test I had locally for it passes. But it turns out the test runner uses by default and the crash now needs to be triggered. I will continue looking into this.
Confirmed, thanks!
Change:
format!("{{{}, {}", import_snippet, start_snippet) }, )); <del> } // Add a `};` to the end if nested, matching the `{` added at the start. if !has_nested { corrections.push((source_map.end_point(after_crate_name), "};".to_string())); </del> <ins> // Add a `};` to the end if nested, matching the `{` added at the start. if !has_nested { corrections.push((source_map.end_point(after_crate_name), "};".to_string())); } } else { // If the root import is module-relative, add the import separately corrections.push(( import.use_span.shrink_to_lo(), format!("use {module_name}::{import_snippet};n"), )); </ins> } }

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: The current output is: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
<ins> //@ check-pass //@ edition:2021 //@ aux-build:rustc-serialize.rs #![crate_type = "lib"] #![allow(deprecated, soft_unstable)] extern crate rustc_serialize; #[derive(RustcDecodable)] pub enum Foo {} </ins>

Discussion:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:
Change:
impl<'a> From<&'a ast::PathSegment> for Segment { fn from(seg: &'a ast::PathSegment) -> Segment { <del> Segment { ident: seg.ident, id: Some(seg.id) } </del> <ins> Segment { ident: seg.ident, id: Some(seg.id), has_generic_args: seg.args.is_some() } </ins> } }

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
<ins> trait Trait {} impl Trait for () {} fn foo<T: Trait, U: Trait>() -> impl Trait { //~^ WARN function cannot return without recursing [unconditional_recursion] let a: T = foo::<T, U>(); //~^ ERROR concrete type differs from previous defining opaque type use loop {} let _: T = foo::<U, T>(); } fn main() {} </ins>

Discussion:
The following code: used to incorrectly compile but now correctly errors, we should add a test to ensure this doesn't regress. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
LL | struct NoMaybeSized<'a, #[pointee] T> { |                                    ^ <ins> error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:59:5 | LL |     #[pointee] |     ^^^^^^^^^^ error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:66:74 | LL | struct PointeeInTypeConstBlock<'a, T: ?Sized = [u32; const { struct UhOh<#[pointee] T>(T); 10 }]> { |                                                                          ^^^^^^^^^^ error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:76:34 | LL |     const V: u32 = { struct UhOh<#[pointee] T>(T); 10 }> |                                  ^^^^^^^^^^ error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:85:56 | LL |     ptr: PointeeInConstConstBlock<'a, T, { struct UhOh<#[pointee] T>(T); 0 }> |                                                        ^^^^^^^^^^ </ins> error[E0392]: lifetime parameter `'a` is never used --> $DIR/deriving-smart-pointer-neg.rs:15:16 |

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
then # Interactive + TTY args="$args -it" <del> command="/bin/bash" </del> <ins> if [ $IS_GIT_SOURCE -eq 1 ]; then command=(/bin/bash -c 'git config --global --add safe.directory /checkout;bash') else command=(/bin/bash) fi </ins> else <del> command="/checkout/src/ci/run.sh" </del> <ins> command=(/checkout/src/ci/run.sh) </ins> fi if [ "$CI" != "" ]; then

Discussion:
I have this totally normal config: Then I want to run Then inside the container, Bootstrap is compiled, but then emits this: My repository history is not too shallow. The only way to use the CI scripts seems to be to set . The reason download-ci-llvm doesn't work seems to be the ownership of the mount: So maybe this is an easy fix? Can we just run that somewhere? It seems to work, I'm just not sure where it would be run.
That script should set the uid of the processes inside the container to match what you use outside of the container and thus who owns the source repo: If you use podman, are you maybe using a version of podman which doesn't contain the literal string in ? And can you run outside and inside the container?
I am not using Podman
Outside the container: After
I assume this is related with your docker privileges (the user group assigned on docker). Can't reproduce this on my side.
That seems reasonable? What should that be instead?
should be able to handle this
That's very nice of you, but if I have a scuffed Docker setup on my dev machine I'd like to know in what way it's scuffed if you don't mind :sweat_smile:
By default, docker runs under root mode, and I believe this is the main issue here. On the other hand, podman runs in rootless mode by default: I was able to reproduce the problem by running podman under root privileges. I believe the problem here is more related to the nature of docker rather than an issue with your docker setup.
The snippet I mentioned in should ensure that the programs inside the container run as the same user as the one with which was invoked.
And when the user is root (e.g., running the script with root user), you get .
Change:
} fn emit_err(&self, sp: Span, expected: Ty<'tcx>, found: Ty<'tcx>, trait_def_id: DefId) { <del> let tcx = self.tcx(); </del> let trait_sp = self.tcx().def_span(trait_def_id); let mut err = self .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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .
Change:
<ins> // Test that dyn Foo<Bar = T> is invariant with respect to T. // Failure to enforce invariance here can be weaponized, see #71550 for details. trait Foo { type Bar; } fn make() -> Box<dyn Foo<Bar = &'static u32>> { panic!() } fn take<'a>(_: &'a u32) { let _: Box<dyn Foo<Bar = &'a u32>> = make(); //~^ ERROR mismatched types [E0308] } fn main() {} </ins>

Discussion:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).
Change:
cargo.arg("--").args(builder.config.cmd.test_args()); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> if !try_run(builder, &mut cargo.into()) { return;

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
<ins> // run-pass fn main() { foo(10); } fn foo(mut n: i32) { if false { n = 0i32; } if n > 0i32 { 1i32 / n; } } </ins>

Discussion:
The following code results in a const eval divide by zero error, when it cannot actually error at runtime:
Bisected to , which corresponds to . cc BTW, you need to actually use (e.g. by calling it in ) to trigger the error. Just adding won't do it.
Fun thing, it doesn't even depend on the conditions in the if clause: also ICEs
Thanks
Change:
// // to work in stable even if the Sized bound on `drop` is relaxed. for i in 0..fn_sig.inputs().skip_binder().len() { <del> let input = tcx.erase_late_bound_regions(&fn_sig.input(i)); </del> <ins> // We just want to check sizedness, so instead of introducing // placeholder lifetimes with probing, we just replace higher lifetimes // with fresh vars. let input = self.replace_bound_vars_with_fresh_vars( expr.span, infer::LateBoundRegionConversionTime::FnCall, &fn_sig.input(i)).0; </ins> self.require_type_is_sized_deferred(input, expr.span, traits::SizedArgumentType); }

Discussion:
does not build on the current nightly because the compiler is unable to infer that a type is . This is a regression in the latest nightly. The line that errors is . Error message: Relevant commits: cc rust-lang-nursery/futures-rs
Minimized example without and external dependencies: .
Possibly caused by cc
Enabling the feature fixes this, so this is being caused by the gate .
Perhaps do I need some normalization before doing deferred ness checking?
triage. This is now a stable-to-beta regression. P-high.
assigning to to either r+ PR , come up with a new fix, or delegate those options to someone else.
Change:
[[package]] name = "libc" <del> version = "0.1.12" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e32a70cf75e5846d53a673923498228bbec6a8624708a9ea5645f075d6276122" [[package]] name = "libc" </del> version = "0.2.112" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1b03d17f364a3a042d5e5d46b053bbbf82c92c9430c592dd4c064dc6ee997125"

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
// No support in vtable for distinguishing destroying with // versus without calling Drop::drop. Assert caller is // okay with always calling the Drop impl, if any. <ins> // FIXME(#36457) -- we should pass unsized values to drop glue as two arguments </ins> assert!(!skip_dtor); let data_ptr = get_dataptr(bcx, v0); let vtable_ptr = Load(bcx, get_meta(bcx, v0));

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
<ins> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:6:5: 6:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:3:1 | LL | type Closure = impl FnOnce(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found () | = note: expected type `Closure` found type `()` = note: the return type of a function must have a statically known size error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:6:5: 6:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:3:1 | LL | type Closure = impl FnOnce(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found () | = note: expected type `Closure` found type `()` = note: the return type of a function must have a statically known size error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
import_ids: import_ids.clone(), kind: TraitCandidate(new_trait_ref), }, <del> true, </del> <ins> false, </ins> ); }); } else {

Discussion:
When a trait alias to a trait with a method with the same name as a method on a struct is in scope, rustc is suddenly unable to disambiguate the trait method from the struct method.
cc
cc and -- Is importing the trait with higher priority than inherent items?
Is importing the trait with higher priority than inherent items? It shouldn't do that, looks like a bug. A method introduced into scope via trait alias (import) should behave identically to methods introduced with a trait (import), that means lower priority than inherent items.