jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: future cannot be sent between threads safely --> $DIR/issue-67252-unnamed-future.rs:18:5 | LL | fn spawn<T: Send>(_: T) {} |    -----    ---- required by this bound in `spawn` ... LL |     spawn(async { |     ^^^^^ future is not `Send` | = help: within `impl std::future::Future`, the trait `std::marker::Send` is not implemented for `*mut ()` note: future is not `Send` as this value is used across an await --> $DIR/issue-67252-unnamed-future.rs:20:9 | LL |         let _a = std::ptr::null_mut::<()>(); // `*mut ()` is not `Send` |             -- has type `*mut ()` LL |         AFuture.await; |         ^^^^^^^^^^^^^ await occurs here, with `_a` maybe used later LL |     }); |     - `_a` is later dropped here error: aborting due to previous error </ins>

Discussion:
I wanted to quickly prototype a bit of code involving tokio and some shared state but ran into a rustc panic: I installed by running rustup update a few hours back. In my code (see below) there seems to be a mistake, having a lock living too long i suppose. The following code leads to the error (based on ) : Unfortunately I could not remove unnecessary parts of the code without making the panic go away. Might this has something to do with detecting the lock lifetimes?
ICE occurs in:
Error before: Regression in cc (I'm on a MCVE)
triage: P-high, removing nomination tag.
Here we go: So takes a type that is , but isn't . That's causing the ICE.
modify labels: -E-needs-mcve
Not sure how to express the for the MCVE here. You can of course use a new struct (like I did before with ), or use a . Interesting this works with as well, but not with other (custom) traits. Maybe because is an ?
Fixed output:
Change:
Dialect: c_uint) -> ValueRef; <ins> pub static LLVMRustDebugMetadataVersion: u32; pub fn LLVMRustAddModuleFlag(M: ModuleRef, name: *c_char, value: u32); </ins> pub fn LLVMDIBuilderCreate(M: ModuleRef) -> DIBuilderRef;

Discussion:
Here's a recent session of mine Even if I continue into my own function (actually the symbol ), I'm not getting any source level debugging. Is there an extra option that I should be passing or should this be "just working"? I compiled a C executable with and I got nice debug-info without doing anything extra in lldb. cc
This is a known issue with the Servo team, fwiw.
Does clang give you usable debug symbols?
I do indeed get nice debugging with clang:
Could you dump the IR from clang and rustc for similar programs?
I'd also be interested in seeing if clang produces dSYM bundles and whether there are any observable differences between them and the ones that rustc produces. Relevant literature at .
This has the two IR outputs:
Clang: rustc: That's some strong difference there.
I spent a while tracking this down due to a red herring, but the actual issue is simple: the DWARF version is too high. As of OS X 10.9, 'dwarfdump' and 'dsymutil', the latter of which is required to aggregate DWARF info from .o files into the final executable, appear to ignore DWARF information with version 3. Rust uses LLVM's default of DWARF 4. clang defaults to DWARF 2 on OS X; in fact, the version of clang distributed with Xcode (but not the version I have installed through MacPorts? too tired to investigate this properly) seems to ignore -gdwarf-3 and above, so probably better to go with 2 than 3. Workaround: . I believe the correct way to solve this is for rustc to set the LLVM module flag "Dwarf Version", as clang does. It should also set "Debug Info Version", which, as far as I can tell, causes a separate issue where anything reading bitcode files using a new version of LLVM (e.g. the versions of llvm-dis or llc compiled by rust) will magically discard all the debug metadata.
you are my new favorite person in the world, thank you for figuring this out!!! I would be more than ok accepting a patch to pass these arguments by default! Pull requests are always welcome :)
Ship it, shipt it! :cactus:
This is a great find indeed!

For anyone interested, here is another source of information on DWARF on Mac OS X: The DWARF standard says that namespaces are not supported yet in version 2. I'd be interested in what the consequences of this are. Other than that I don't think we use anything that needs a newer version than 2. I'd be happy to turn this information into a fix and a pull request but I don't have a Mac to test it (yet). Thanks again :+1:
cc me
Change:
<ins> // Copyright 2014 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. // aux-build:issue-16643.rs extern crate i = "issue-16643"; pub fn main() { i::TreeBuilder::<uint>.process_token(); } </ins>

Discussion:
Extracted from an issue I encountered upgrading to Rust master. : : It seems like more or less every part of this code is necessary to hit the bug. Here's the result: (This has my modifications to give a marginally more useful error message.) The failure happens when when handling the case. What I actually get building is a failure of the preceding assertion regarding crate IDs. I didn't find a small reproducer for that assertion failure, but this bug is likely to be related.
cc me
(Slightly) simpler example: This appears to be related to AST being inlined cross-crate, and the internals (cc since desugaring it to the equivalent doesn't ICE. It also requires that is a method, a freestanding function stops the ICE.
Cool, for now I'll go with the workaround of desugaring the loop myself.
Change:
}, "vis" => { // Explicitly disallow `priv`, on the off chance it comes back. <del> let tokens = vec!["`,`", "an ident", "a type"]; </del> <ins> const TOKENS: &[&str] = &["`,`", "an ident", "a type"]; </ins> match tok { TokenTree::Token(token) => match token.kind { Comma => IsInFollow::Yes,

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
pub fn uv_udp_set_multicast_ttl(handle: *mut uv_udp_t, ttl: c_int) -> c_int; pub fn uv_udp_set_ttl(handle: *mut uv_udp_t, ttl: c_int) -> c_int; pub fn uv_udp_set_broadcast(handle: *mut uv_udp_t, on: c_int) -> c_int; <del> pub fn uv_udp_getsockname(h: *mut uv_udp_t, name: *mut sockaddr, </del> <ins> pub fn uv_udp_getsockname(h: *const uv_udp_t, name: *mut sockaddr, </ins> len: *mut c_int) -> c_int; // timer bindings

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
PatternKind::Constant { value } => { match *constructor { Slice(..) => { <del> if let Some(ptr) = value.to_ptr() { let is_array_ptr = value.ty .builtin_deref(true) .and_then(|t| t.ty.builtin_index()) .map_or(false, |t| t == cx.tcx.types.u8); assert!(is_array_ptr); let data_len = cx.tcx .alloc_map .lock() .unwrap_memory(ptr.alloc_id) .bytes .len(); if wild_patterns.len() == data_len { Some(cx.lower_byte_str_pattern(pat)) } else { None </del> <ins> // we extract an `Option` for the pointer because slices of zero elements don't // necessarily point to memory, they are usually just integers. The only time // they should be pointing to memory is when they are subslices of nonzero // slices let (opt_ptr, n, ty) = match value.ty.builtin_deref(false).unwrap().ty.sty { ty::TyKind::Array(t, n) => (value.to_ptr(), n.unwrap_usize(cx.tcx), t), ty::TyKind::Slice(t) => { match value.val { ConstValue::ScalarPair(ptr, n) => ( ptr.to_ptr().ok(), n.to_bits(cx.tcx.data_layout.pointer_size).unwrap() as u64, t, ), _ => span_bug!( pat.span, "slice pattern constant must be scalar pair but is {:?}", value, ), } }, _ => span_bug!( pat.span, "unexpected const-val {:?} with ctor {:?}", value, constructor, ), }; if wild_patterns.len() as u64 == n { // convert a constant slice/array pattern to a list of patterns. match (n, opt_ptr) { (0, _) => Some(Vec::new()), (_, Some(ptr)) => { let alloc = cx.tcx.alloc_map.lock().unwrap_memory(ptr.alloc_id); let layout = cx.tcx.layout_of(cx.param_env.and(ty)).ok()?; (0..n).map(|i| { let ptr = ptr.offset(layout.size * i, &cx.tcx).ok()?; let scalar = alloc.read_scalar( &cx.tcx, ptr, layout.size, ).ok()?; let scalar = scalar.not_undef().ok()?; let value = ty::Const::from_scalar(cx.tcx, scalar, ty); let pattern = Pattern { ty, span: pat.span, kind: box PatternKind::Constant { value }, }; Some(&*cx.pattern_arena.alloc(pattern)) }).collect() }, (_, None) => span_bug!( pat.span, "non zero length slice with const-val {:?}", value, ), </ins> } } else { <del> span_bug!(pat.span, "unexpected const-val {:?} with ctor {:?}", value, constructor) </del> <ins> None </ins> } } _ => {

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
LL | #![deny(unreachable_patterns)] |         ^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to previous error </del> <ins> error: unreachable pattern --> $DIR/unreachable-loop-patterns.rs:20:14 | LL |     for _ in unimplemented!() as Void {} |              ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>

Discussion:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.
Change:
<ins> Future incompatibility report: Future breakage diagnostic: warning: use of unstable library feature 'rustc_encodable_decodable': derive macro for `rustc-serialize`; should not be used in new code --> $DIR/rustc-decodable-issue-123156.rs:10:10 | LL | #[derive(RustcDecodable)] |          ^^^^^^^^^^^^^^ | = 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 #64266 <https://github.com/rust-lang/rust/issues/64266> </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:
$$(LLVM_CONFIG_$(1)): $$(LLVM_DEPS) $$(LLVM_STAMP_$(1)) @$$(call E, make: llvm) <del> $$(Q)$$(MAKE) -C $$(CFG_LLVM_BUILD_DIR_$(1)) $$(CFG_LLVM_BUILD_ENV_$(1)) </del> <ins> $$(Q)$$(MAKE) -C $$(CFG_LLVM_BUILD_DIR_$(1)) $$(CFG_LLVM_BUILD_ENV_$(1)) ONLY_TOOLS="$$(LLVM_TOOLS)" </ins> $$(Q)touch $$(LLVM_CONFIG_$(1)) endif

Discussion:
Today error :
I've heard the error from IRC: misses , but invoking again seems to work well.
Yes I just successfully build it today, thanks
I think the first error is significant and should be fixed (no need to re-). Could you reopen it?
wait... but it's building without errors for me now... Do you mean it's working only because I run build second time?
llvm build is triggered only if you haven't built it before or llvm has been upgraded. So I guess llvm fails to complete, but it anyway succeeded to make some binary we use.
I will try to reproduce with clean build
Right, it's still being failing if I build it first time ( or even if I remove i686-... (build) folder ) with the same error.
What version of mingw/gcc did you use? would show and/or . (If both values exist, trust the second one.)
I also reproduced the error on mingw 4.0 / gcc 4.8.1.
I'm having the same issue:
I'm also having this issue. Same version information as
I am also getting the error. Same versions as ameyp. Any more info on this?
According to , this error happens because this particular binary (llvm-c-test) is compiled with -std=c99 flag. Apparently 'offt' is not in ANSI standard, so mingw's specifically omits it when is defined.
Change:
name: Option<String>, ) -> Vec<Item> where F: Fn(DefId) -> Def { <ins> debug!("get_blanket_impls(def_id={:?}, ...)", def_id); </ins> let mut impls = Vec::new(); if self.cx .tcx

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
<ins> // Copyright 2013 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. // On Windows this test checks that Rust binaries have an embedded // application manifest and don't trip UAC installer detection // heuristics ("setup" is one of the "installer" keywords). // For details, see issue #10512. // On other platforms this is a no-op. pub fn main() { } </ins>

Discussion:
Windows executables should contain embedded application manifests [1]. This is especially important for 32-bit executables, because in the absence of a manifest they are subject to UAC installer detection heuristics [2], which may cause unexpected UAC prompts or even complete failure to execute (in unattended contexts) depending on presence of certain keywords in executable's file name.
You beat me by a few hours :) Here is the description I had in : The UAC issue in is caused by a missing in the binaries. We should include the following in all binaries: In an ideal world, we would allow the user to provide a custom manifest should they wish to require UAC elevation, for example. As another example, a user might want to provide entries in order to fully support Windows 8.1 (where the / functions unless is present in the manifest). The VC++ linker has the option for the UAC part. In a traditional MinGW build, this would be implemented something like this: Where would contain something like this (application.manifest would contain the XML stuff above):
I wonder if it would be easier to skip windres altogether and write resource directly into linked executable using .
I use to add manifest but I always felt this is a hack.
As of MSVC 2008, passing to should add the necessary manifest bits for UAC.
In case anyone finds this issue, you can use in a script to solve this:
Hello. It is over 1 year later now since this comment was posted. Is this nasty work around still necessary? Or does the Rust Compiler finally supports embedding Windows Manifest Files and Resources etc. (in anyway whatsoever)? Thanks!
Change:
pub(super) fn generics_of(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ty::Generics { use rustc_hir::*; <ins> // For an RPITIT, synthesize generics which are equal to the opaque's generics // and parent fn's generics compressed into one list. if let Some(ty::ImplTraitInTraitData::Trait { fn_def_id, opaque_def_id }) = tcx.opt_rpitit_info(def_id.to_def_id()) { let trait_def_id = tcx.parent(fn_def_id); let opaque_ty_generics = tcx.generics_of(opaque_def_id); let opaque_ty_parent_count = opaque_ty_generics.parent_count; let mut params = opaque_ty_generics.params.clone(); let parent_generics = tcx.generics_of(trait_def_id); let parent_count = parent_generics.parent_count + parent_generics.params.len(); let mut trait_fn_params = tcx.generics_of(fn_def_id).params.clone(); for param in &mut params { param.index = param.index + parent_count as u32 + trait_fn_params.len() as u32 - opaque_ty_parent_count as u32; } trait_fn_params.extend(params); params = trait_fn_params; let param_def_id_to_index = params.iter().map(|param| (param.def_id, param.index)).collect(); return ty::Generics { parent: Some(trait_def_id), parent_count, params, param_def_id_to_index, has_self: opaque_ty_generics.has_self, has_late_bound_regions: opaque_ty_generics.has_late_bound_regions, host_effect_index: parent_generics.host_effect_index, }; } </ins> let hir_id = tcx.local_def_id_to_hir_id(def_id); let node = tcx.hir_node(hir_id);

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
}; use rustc_session::config::{self, DebugInfo, Lto}; use rustc_span::symbol::Symbol; <del> use rustc_span::FileName; </del> <ins> use rustc_span::{hygiene, FileName, DUMMY_SP}; </ins> use rustc_span::{FileNameDisplayPreference, SourceFile}; use rustc_symbol_mangling::typeid_for_trait_ref; use rustc_target::abi::{Align, Size};

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 code: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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
Change:
tcx, infcx.fresh_substs_for_item(DUMMY_SP, impl_def_id), ); <del> // I guess we don't need to make a universe unless we need it, // but also we're on the error path, so it doesn't matter here. let universe = infcx.create_next_universe(); </del> <ins> let value = tcx.fold_regions(qself_ty, |_, _| tcx.lifetimes.re_erased); // FIXME: Don't bother dealing with non-lifetime binders here... if value.has_escaping_bound_vars() { return false; } </ins> infcx .can_eq( ty::ParamEnv::empty(), impl_.self_ty(), <del> tcx.replace_escaping_bound_vars_uncached(qself_ty, ty::fold::FnMutDelegate { regions: &mut |_| tcx.lifetimes.re_erased, types: &mut |bv| tcx.mk_placeholder(ty::PlaceholderType { universe, bound: bv, }), consts: &mut |bv, ty| tcx.mk_const(ty::PlaceholderConst { universe, bound: bv, }, ty), }) </del> <ins> value, </ins> ) }) && tcx.impl_polarity(impl_def_id) != ty::ImplPolarity::Negative

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
Regression in cc
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. mod A; use self::A::*; </ins>

Discussion:
This code compiles: However, splitting the code into files causes compilation to fail: I am not sure whether or use is correct; regardless, replacing the latter with the former in produces a similar error:
cc
This appears to work now.