jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(staged_api)] #![feature(inherent_associated_types)] #![stable(feature = "main", since = "1.0.0")] #[stable(feature = "main", since = "1.0.0")] pub struct Owner; impl Owner { #[unstable(feature = "data", issue = "none")] pub type Data = (); } </ins>

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
if let Some(id) = def_id.as_local() { self.local_macro_def_scopes[&id] } else { <del> let module_def_id = ty::DefIdTree::parent(&*self, def_id).unwrap(); self.get_module(module_def_id) </del> <ins> // This is not entirely correct - a `macro_rules!` macro may occur // inside a 'block' module: // // ```rust // const _: () = { // #[macro_export] // macro_rules! my_macro { //     () => {}; // } // ` // We don't record this information for external crates, so // the module we compute here will be the closest 'mod' item // (not necesssarily the actual parent of the `macro_rules!` // macro). `macro_rules!` macros can't use def-site hygiene, // so this hopefully won't be a problem. // // See https://github.com/rust-lang/rust/pull/77984#issuecomment-712445508 self.nearest_mod_parent(def_id) </ins> } }

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
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 nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
<del> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:10:14 | LL | / const INVALID_VTABLE_ALIGNMENT: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: alignment `1000` is not a power of 2 | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:16:14 | LL | / const INVALID_VTABLE_SIZE: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: size is bigger than largest supported object | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to 2 previous errors </del>

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
) .report(diag); <del> (is_simple_err, Some(exp_found)) </del> <ins> (is_simple_err, Mismatch::Variable(exp_found)) </ins> } <del> _ => (false, None), </del> <ins> ValuePairs::TraitRefs(_) => (false, Mismatch::Fixed("trait")), _ => (false, Mismatch::Fixed("type")), </ins> }; let vals = match self.values_str(&values) { Some((expected, found)) => Some((expected, found)),

Discussion:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".
Change:
$(foreach host,$(CFG_HOST), $(eval $(call DEF_INSTALLER,$(host)))) <del> $(foreach target,$(CFG_TARGET), </del> <ins> # When generating packages for the standard library, we've actually got a lot of # artifacts to choose from. Each of the CFG_HOST compilers will have a copy of # the standard library for each CFG_TARGET, but we only want to generate one # standard library package. As a result, for each entry in CFG_TARGET we need to # pick a CFG_HOST to get the standard library from. # # In theory it doesn't actually matter what host we choose as it should be the # case that all hosts produce the same set of libraries for a target (regardless # of the host itself). Currently there is a bug in the compiler, however, which # means this is not the case (see #29228 and #29235). To solve the first of # those bugs, we prefer to select a standard library from the host it was # generated from, allowing plugins to work in more situations. # # For all CFG_TARGET entries in CFG_HOST, however, we just pick CFG_BUILD as the # host we slurp up a standard library from. $(foreach host,$(CFG_HOST), $(eval $(call DEF_INSTALLER_TARGETS,$(host),$(host)))) $(foreach target,$(filter-out $(CFG_HOST),$(CFG_TARGET)), </ins> $(eval $(call DEF_INSTALLER_TARGETS,$(CFG_BUILD),$(target)))) ifdef CFG_WINDOWSY_$(CFG_BUILD)

Discussion:
This fails to build: NB. I'm on an x86-64 computer, but I installed and am running a i686 compiler via multirust: It also , where the i686 installer is and manually. I guess this may be some issue with how multirust/that installation works.
This looks like it's because the host libs are different from the target libs (in theory shouldn't ever happen). Possible cause: the i686 libstd package is actually a bunch of libraries produced by a x8664 compiler, it may be the case that the symbols or something along the line is dependent on the architecture that produced the artifact. The i686 host libs, however, are produced by an i686 compiler. I think due to the way hashing works the same library compiled by an i686 compiler vs x8664 compiler (even if for the same target) will produce different binaries (causing the discrepancy here). This... seems like we should be more picky about picking libs to ship!
Change:
LL |     #[doc(alias = "assoc")] |           ^^^^^^^^^^^^^^^ <del> error: aborting due to 4 previous errors </del> <ins> error: aborting due to 5 previous errors </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
ICE only appears since 1.52. label regression-from-stable-to-stable
Better-looking code example Bisection points to
Reading the descriptions, I’d guess most likely , cc
This is indeed caused by since we're now checking parameters unlike before. The issue is in when . The call to panics because there is no name for a param. The question I have is whether we should support params for doc aliases. I didn't find anything in the tracking issue to indicate that it was supposed to be supported, and I personally don't think it makes sense. If we decide to not support doc aliases for params, then it should be an easy change to to error when is a . cc
Doc aliases are only supported for items showing up in doc search, function parameters don't, so in this case, it should error on the doc alias attribute.
Do you want to send a fix or should I?
I'll submit a fix.
Thanks! Please ping me on it (and don't forget to add a test for it too ;) ).
Change:
use std::io::timer; use mem; <del> let mut tb = TaskBuilder::new(); </del> <ins> let tb = TaskBuilder::new(); </ins> let rx = tb.try_future(proc() {}); mem::drop(rx); timer::sleep(1000);

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
<ins> error[E0521]: borrowed data escapes outside of method --> $DIR/ice-on-non-ref-sig-ty.rs:13:9 | LL | impl<'a> W<'a> for &'static () { |      -- lifetime `'a` defined here LL |     fn g<T>(self, x: &'a T) -> &'static T { |             ----  - `x` is a reference that is only valid in the method body |             | |             `self` declared here, outside of the method body LL |         f(&self, x) |         ^^^^^^^^^^^ |         | |         `x` escapes the method body here |         argument requires that `'a` must outlive `'static` error[E0597]: `self` does not live long enough --> $DIR/ice-on-non-ref-sig-ty.rs:13:11 | LL | impl<'a> W<'a> for &'static () { |                     ------- has lifetime `'static` LL |     fn g<T>(self, x: &'a T) -> &'static T { |                                 ------- also has lifetime `'static` LL |         f(&self, x) |           ^^^^^ `self` would have to be valid for `'static`... ... LL |     } |      - ...but `self` will be dropped here, when the function `g` returns | = help: use data from the highlighted arguments which match the `'static` lifetime of the return type = note: functions cannot return a borrow to data owned within the function's scope, functions can only return borrows to data passed as arguments = note: to learn more, visit <https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#dangling-references> error: aborting due to 2 previous errors Some errors have detailed explanations: E0521, E0597. For more information about an error, try `rustc --explain E0521`. </ins>

Discussion:
I'll even accept that this is probably UB if I somehow make it work but crashing on is probably not the way. Replacing some with , or with a second lifetime parameter correctly rejects the code. : <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-06-08 fetching (via remote github) commits from max(, 2022-06-05) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 7 commit[0] 2022-06-06: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2022-06-06: Auto merge of - matthiaskrgr:rollup-ajyvjd3, r=matthiaskrgr commit[2] 2022-06-07: Auto merge of - RalfJung:miri, r=RalfJung commit[3] 2022-06-07: Auto merge of - jackh726:remove-borrowck-mode, r=nikomatsakis commit[4] 2022-06-07: Auto merge of - scottmcm:add-coldcc, r=nagisa,lcnr commit[5] 2022-06-07: Auto merge of - Dylan-DPC:rollup-ya51k1k, r=Dylan-DPC commit[6] 2022-06-07: Auto merge of - Dylan-DPC:rollup-0ae3pwp, r=Dylan-DPC
Likely .
Change:
attrs.push(inert_attr); attrs }); <ins> return Err(Determinacy::Undetermined) </ins> } <del> return Err(Determinacy::Undetermined); </del> }, Err(Determinacy::Undetermined) => determinacy = Determinacy::Undetermined, Err(Determinacy::Determined) => {}

Discussion:
Originally reported as this is reduced to: compiles with:
cc I'm not really sure what this classifies under, it seems like maybe although doesn't break it, only does. After though it may be broken by (I'm not 100% sure where this is happening)
I'm not really sure what this classifies under, it seems like maybe although doesn't break it This falls under and .
I hit this error last week when trying to update a crate that used 's derive macros. I found that ing the macro would give me the attribute error, but ing the crate worked.
I think that may be a separate bug, can you file a different issue? I believe I've fixed this issue in
Change:
| clean::UnionItem(..) | clean::AssocConstItem(..) | clean::TraitAliasItem(..) <ins> | clean::MacroItem(..) </ins> | clean::ForeignTypeItem => { if i.def_id.is_local() { if !self.access_levels.is_exported(i.def_id.expect_def_id()) {

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: is hidden from the documentation. Instead, this happened: is shown in the documentation and has its own page. Private declarative macros are also shown. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: rustc 1.56.0-nightly ( 2021-08-14) <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged +A-macros +A-visibility +T-rustdoc --
modify labels +requires-nightly
Thanks for filing this issue! This regression was almost certainly introduced in . I'm looking into it.
Assigning priority as in the prioritization working group. label: +P-high -I-prioritize
Thanks
Change:
Load(cx, ptr) }; <ins> unsafe { llvm::LLVMSetAlignment(val, align); } </ins> from_arg_ty(cx, val, t) } /// Helper for storing values in memory. Does the necessary conversion if the in-memory type /// differs from the type used for SSA values. pub fn store_ty<'blk, 'tcx>(cx: Block<'blk, 'tcx>, v: ValueRef, dst: ValueRef, t: Ty<'tcx>) { <del> Store(cx, to_arg_ty(cx, v, t), to_arg_ty_ptr(cx, dst, t)); </del> <ins> if cx.unreachable.get() { return; } let store = Store(cx, to_arg_ty(cx, v, t), to_arg_ty_ptr(cx, dst, t)); unsafe { llvm::LLVMSetAlignment(store, type_of::align_of(cx.ccx(), t)); } </ins> } pub fn to_arg_ty(bcx: Block, val: ValueRef, ty: Ty) -> ValueRef {

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
let out_dir = build.cargo_out(compiler, Mode::Libstd, target); build.clear_if_dirty(&out_dir, &build.compiler_path(compiler)); let mut cargo = build.cargo(compiler, Mode::Libstd, target, "build"); <del> cargo.arg("--features").arg(build.std_features()) </del> <ins> let mut features = build.std_features(); // When doing a local rebuild we tell cargo that we're stage1 rather than // stage0. This works fine if the local rust and being-built rust have the // same view of what the default allocator is, but fails otherwise. Since // we don't have a way to express an allocator preference yet, work // around the issue in the case of a local rebuild with jemalloc disabled. if compiler.stage == 0 && build.local_rebuild && !build.config.use_jemalloc { features.push_str(" force_alloc_system"); } cargo.arg("--features").arg(features) </ins> .arg("--manifest-path") .arg(build.src.join("src/rustc/std_shim/Cargo.toml"));

Discussion:
Edit: see Seems to get past there fine if I remove .
Ok, works. That's the version rustbuild will download if left to its own devices. Bisecting built nightlies as my local rust gives this: nightly-2016-12-19 () - works [no nightlies] nightly-2016-12-29 - unrelated errors on some i128/u128 stuff before it gets to the relevant point [no nightlies] nightly-2017-01-04 () - broken
Note that this is really quick to reproduce (~1min), as it happens on the initial build of stage0 std. Here's the full log from : This issue may get a lot more attention once the stage0 downloaded compiler has its version bumped, as I suspect will be totally broken. Applying seems to fix it.
Ah I see, the more recent compiler is being detected as a local rebuild compiler, so rustbuild assumes it has a compiler with stage1 features and therefore performs a stage1 build, which seems to assume that jemalloc is available. On a positive note, this should never affect someone not using .
Ok I have a more solid understanding of the issue. Currently, a stage0-out libstd will never link against jemalloc. stage1-out is left to its own devices, linking against the default allocator for the compiler that's just been created (stage0-out) which is , system otherwise. However, a local rebuild uses for building the stage0 libstd, which means it uses the default allocator for the local rust. This tends to be we've disabled jemalloc, so it hasn't been built! Something along the lines of seems like the right approach, but I think some elaboration around the logic in this area is necessary in comments or something.
Change:
clippy_info, miri_info, rustfmt_info, <ins> in_tree_llvm_info, emscripten_llvm_info, </ins> cc: HashMap::new(), cxx: HashMap::new(), ar: HashMap::new(),

Discussion:
Which means that programs that run from a build script, or from cargo in some other way, fail. Steps to Reproduce: a clang binary pointing to clang-8 installed and in your path. install nightly clone && cd $ test Actual results: /usr/bin/clang: relocation error: symbol ZTIN4llvm14FoldingSetBaseE version LLVM8 not defined in file libLLVM-8.so with link time reference Expected results: not so This only happens if ran from cargo, if I run the test executable manually then stuff works, so I suspect this is some LDLIBRARYPATH mungling that cargo or rustup do under the hood. This is technically a regression from , same problem does not exist with rust stable / beta and clang 7. There's a slight chance that there's an issue on how clang-8 is built in Fedora, so I also filed , but I think it's unexpected that clang when called from cargo / build scripts uses rust's , and probably should be avoided. cc
Is invoked from a build script? It is possible that cargo neglects removing the unnecessary or similar environment variables before invoking the script in question. EDIT: oh you wrote that in the report already. I remember there being an issue like this in cargo repo from a long long time ago, but cannot find it now.
cc
See also . We should probably set a custom suffix per . Maybe even include the Rust version to help avoid bootstrap issues like what commit saw. (cc
Yep, I think a suffix of rust version (or maybe LLVM submodule commit?) would be good. I think we'd appreciate a PR for something like that; I would expect it to be a matter of making the version suffix default be or something along those lines.
Sure, that sounds good, I can give that a shot.
I sent with a change that I hope will address this, but see there why I cannot confirm it will :)
triage: P-high, assigning to
Change:
_ => ccx.sess().bug("get_item_val: weird result in table") }; <del> match attr::first_attr_value_str_by_name(&i.attrs, "link_section") { Some(sect) => { if contains_null(&sect) { ccx.sess().fatal(&format!("Illegal null byte in link_section value: `{}`", &sect)); } unsafe { let buf = CString::new(sect.as_bytes()).unwrap(); llvm::LLVMSetSection(v, buf.as_ptr()); } }, None => () } </del> v }

Discussion:
I compile the code below: using compiler version 1.3.0-nightly ( 2015-07-27) with the following command line: As result I get the following symbol inside a produced rlib:
How'd you verify this? I tried a few variants myself and it looks like it works.
It's broken in Nightly release. Try the following code in after choosing 'Asm' and 'Nightly'.
Aha, looks like I was using an older nightly. cc some informal bisecting turns up as a suspicious commit
Yes, that bisection is correct; PR coming up.