jiebi/CodeConvo huggingface dataset:
Code change:
Hi, I've been giving rust a try and hit my first compiler bug today. I was playing around with traits and ran into an error with the following code: In particular it seems it's the last line in that breaks things, if I comment that out it compiles (and runs) without issue. Here's output from rustc: I am using on OS X 10.9.4
Looke like this no longer ICE-s: Now produces: Which seems like the right error message. Please reopen if you are still having trouble. Please reopen if you are still

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
Some of core methods using macros. Like and of and . I found two primary things about this: () (, ) Seems like some of fail (panic) methods will be preserved (like for a ). But using of such methods is highly error-prone. To prevent mass usage of them I suggest to mark such methods as . For example:
is used for operations that are memory unsafe. marking (supposed) code smells as would only pollute when or when not to use it. notice memory unsafe is a very clear definition, unsafe does not mean this code might be broken, per se. (as i understand this)
is for drawing a boundary between memory unsafe and memory safe code It's not used to discourage the usage of safe APIs as that would break down the boundary and make it harder to identify memory safety issues. Usage of and is common in correct code, because there are invariants that are not encoded into the type system. Changing the meaning of would be a fundamental change to the design of the language / libraries so it would need to go through the RFC process (but it wouldn't be accepted).
(now at )

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
Let's say that you have a JSON document similar to this: And the value of can be either a number or a string. There is currently no way to write a generic implementation of that can handle this. Attempting to read the value of will remove it and throw it away, even if the read triggers an error. You can't try to read a number and then read a string if it fails. The element is returned in the , so it should be possible to write an implementation of specifically for Json, but if you do so you can't put the object within another object that has .
Can it not map to the enum?
The enum doesn't implement . It's probably for this reason.
Duplicate of Should I close this?

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
Code: Compile, run, result is Sorry, cannot find smaller example to reproduce the problem. Similar code, internal compiler error:
Smaller:
Looks like a libstd bug: could you file a separate issue for the internal compiler error?

Related discussion:
text: impl<'a> Writer for &'a mut Writer+'a { #[inline] <del> fn write(&mut self, buf: &[u8]) -> IoResult<()> { self.write(buf) } </del> <ins> fn write(&mut self, buf: &[u8]) -> IoResult<()> { (**self).write(buf) } </ins> #[inline] <del> fn flush(&mut self) -> IoResult<()> { self.flush() } </del> <ins> fn flush(&mut self) -> IoResult<()> { (**self).flush() } </ins> } /// A `RefWriter` is a struct implementing `Writer` which contains a reference
Code change:
Noticed in . This is either a really odd way to ask for the version, or a bit of advice that's no longer relevant. What should we say instead? is a bit too_ verbose — I killed it after it wrote 8.1 GB of logs compiling .
I think the intent was indeed to get the version output. I think the phrasing is only odd in that it does not make that intent clear. (It is possible I am wrong about the intent here.) But there is an additional problem: Sometime between 0.10 and 0.11, we revised the / output to ensure it would be only one line when you do not supply an argument to . This means we lose potentially relevant information, namely the host system type (e.g. or ). We could fix both of these problems by revising the instructions to say something like:
Closing since was merged.

Related discussion:
text: It generally helps our diagnosis to include your specific OS (for example: Mac OS X 10.8.3, Windows 7, Ubuntu 12.04) and your hardware architecture (for example: i686, x86_64). <del> It's also helpful to copy/paste the output of re-running the erroneous rustc command with the `-v` flag. Finally, if you can run the offending command under gdb, pasting a stack trace can be useful; to do so, you will need to set a breakpoint on `rust_fail`. </del> <ins> It's also helpful to provide the exact version and host by copying the output of re-running the erroneous rustc command with the `--version=verbose` flag, which will produce something like this: ```{ignore} rustc 0.12.0 (ba4081a5a 2014-10-07 13:44:41 -0700) binary: rustc commit-hash: ba4081a5a8573875fed17545846f6f6902c8ba8d commit-date: 2014-10-07 13:44:41 -0700 host: i686-apple-darwin release: 0.12.0 ``` Finally, if you can run the offending command under gdb, pasting a stack trace can be useful; to do so, you will need to set a breakpoint on `rust_fail`. </ins> # I submitted a bug, but nobody has commented on it!
Code change:
When trying to do development on the stage1 compiler, I've been hitting a link error. I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler. But we can and should still try to increase the coverage of bors to handle at least building from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
In case anyone is curious, the problem also occurs on Linux. I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , then things proceed just fine. This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)
(I edited the PR description but forgot that github closes issues based on the original commit message.) I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the build itself, and also adding rules that will force bors to gate on continuing to build.

Related discussion:
text: $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)):  $$(TEST_SREQ$(1)_T_$(2)_H_$(3))  <del> $$(PRETTY_DEPS_$(4)) </del> <ins> $$(PRETTY_DEPS_$(4))  $$(PRETTY_DEPS$(1)_H_$(3)_$(4)) </ins> @$$(call E, run pretty-rpass [$(2)]: $$<) $$(Q)$$(call CFG_RUN_CTEST_$(2),$(1),$$<,$(3))  $$(PRETTY_ARGS$(1)-T-$(2)-H-$(3)-$(4))
Code change:
Technically speaking the negative duration is not the valid ISO 8601, but we need to print it anyway. This code: Produces: Should be , in fact Should be , in fact
Cc

Related discussion:
text: impl fmt::Show for Duration { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> let days = self.num_days(); let secs = self.secs - days * SECS_PER_DAY; </del> <ins> // technically speaking, negative duration is not valid ISO 8601, // but we need to print it anyway. let (abs, sign) = if self.secs < 0 { (-self, "-") } else { (*self, "") }; let days = abs.secs / SECS_PER_DAY; let secs = abs.secs - days * SECS_PER_DAY; </ins> let hasdate = days != 0; <del> let hastime = (secs != 0 || self.nanos != 0) || !hasdate; </del> <ins> let hastime = (secs != 0 || abs.nanos != 0) || !hasdate; try!(write!(f, "{}P", sign)); </ins> <del> try!(write!(f, "P")); </del> if hasdate { <del> // technically speaking the negative part is not the valid ISO 8601, // but we need to print it anyway. </del> try!(write!(f, "{}D", days)); } if hastime { <del> if self.nanos == 0 { </del> <ins> if abs.nanos == 0 { </ins> try!(write!(f, "T{}S", secs)); <del> } else if self.nanos % NANOS_PER_MILLI == 0 { try!(write!(f, "T{}.{:03}S", secs, self.nanos / NANOS_PER_MILLI)); } else if self.nanos % NANOS_PER_MICRO == 0 { try!(write!(f, "T{}.{:06}S", secs, self.nanos / NANOS_PER_MICRO)); </del> <ins> } else if abs.nanos % NANOS_PER_MILLI == 0 { try!(write!(f, "T{}.{:03}S", secs, abs.nanos / NANOS_PER_MILLI)); } else if abs.nanos % NANOS_PER_MICRO == 0 { try!(write!(f, "T{}.{:06}S", secs, abs.nanos / NANOS_PER_MICRO)); </ins> } else { <del> try!(write!(f, "T{}.{:09}S", secs, self.nanos)); </del> <ins> try!(write!(f, "T{}.{:09}S", secs, abs.nanos)); </ins> } } Ok(())
Code change:
Technically speaking the negative duration is not the valid ISO 8601, but we need to print it anyway. This code: Produces: Should be , in fact Should be , in fact
Cc

Related discussion:
text: let d: Duration = Zero::zero(); assert_eq!(d.to_string(), "PT0S".to_string()); assert_eq!(Duration::days(42).to_string(), "P42D".to_string()); <del> assert_eq!(Duration::days(-42).to_string(), "P-42D".to_string()); </del> <ins> assert_eq!(Duration::days(-42).to_string(), "-P42D".to_string()); </ins> assert_eq!(Duration::seconds(42).to_string(), "PT42S".to_string()); assert_eq!(Duration::milliseconds(42).to_string(), "PT0.042S".to_string()); assert_eq!(Duration::microseconds(42).to_string(), "PT0.000042S".to_string()); assert_eq!(Duration::nanoseconds(42).to_string(), "PT0.000000042S".to_string()); assert_eq!((Duration::days(7) + Duration::milliseconds(6543)).to_string(), "P7DT6.543S".to_string()); <ins> assert_eq!(Duration::seconds(-86401).to_string(), "-P1DT1S".to_string()); assert_eq!(Duration::nanoseconds(-1).to_string(), "-PT0.000000001S".to_string()); </ins> // the format specifier should have no effect on `Duration` assert_eq!(format!("{:30}", Duration::days(1) + Duration::milliseconds(2345)),
Code change:
The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.

Related discussion:
text: unsafe { let ccx = cx.fcx.ccx; let ty = val_ty(fn_); <del> let retty = if ty.kind() == llvm::Integer { </del> <ins> let retty = if ty.kind() == llvm::Function { </ins> ty.return_type() } else { ccx.int_type()
Code change:
The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.

Related discussion:
text: <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. // error-pattern:stop // #18576 // Make sure that an calling extern function pointer in an unreachable // context doesn't cause an LLVM assertion #[allow(unreachable_code)] fn main() { panic!("stop"); let pointer = other; pointer(); } extern fn other() {} </ins>
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: use common::{CodegenCx, val_ty}; use declare; use monomorphize::Instance; <ins> use syntax_pos::Span; use syntax_pos::symbol::LocalInternedString; </ins> use type_::Type; use type_of::LayoutLlvmExt; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::layout::{Align, LayoutOf}; <del> use rustc::hir::{self, CodegenFnAttrFlags}; </del> <ins> use rustc::hir::{self, CodegenFnAttrs, CodegenFnAttrFlags}; </ins> use std::ffi::{CStr, CString};
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: let ty = instance.ty(cx.tcx); let sym = cx.tcx.symbol_name(instance).as_str(); <ins> debug!("get_static: sym={} instance={:?}", sym, instance); </ins> let g = if let Some(id) = cx.tcx.hir.as_local_node_id(def_id) { let llty = cx.layout_of(ty).llvm_type(cx);
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: hir_map::NodeForeignItem(&hir::ForeignItem { ref attrs, span, node: hir::ForeignItemKind::Static(..), .. }) => { <del> let g = if let Some(linkage) = cx.tcx.codegen_fn_attrs(def_id).linkage { // If this is a static with a linkage specified, then we need to handle // it a little specially. The typesystem prevents things like &T and // extern "C" fn() from being non-null, so we can't just declare a // static and call it a day. Some linkages (like weak) will make it such // that the static actually has a null value. let llty2 = match ty.sty { ty::TyRawPtr(ref mt) => cx.layout_of(mt.ty).llvm_type(cx), _ => { cx.sess().span_fatal(span, "must have type `*const T` or `*mut T`"); } }; unsafe { // Declare a symbol `foo` with the desired linkage. let g1 = declare::declare_global(cx, &sym, llty2); llvm::LLVMRustSetLinkage(g1, base::linkage_to_llvm(linkage)); // Declare an internal global `extern_with_linkage_foo` which // is initialized with the address of `foo`.  If `foo` is // discarded during linking (for example, if `foo` has weak // linkage and there are no definitions), then // `extern_with_linkage_foo` will instead be initialized to // zero. let mut real_name = "_rust_extern_with_linkage_".to_string(); real_name.push_str(&sym); let g2 = declare::define_global(cx, &real_name, llty).unwrap_or_else(||{ cx.sess().span_fatal(span, &format!("symbol `{}` is already defined", &sym)) }); llvm::LLVMRustSetLinkage(g2, llvm::Linkage::InternalLinkage); llvm::LLVMSetInitializer(g2, g1); g2 } } else { // Generate an external declaration. declare::declare_global(cx, &sym, llty) }; (g, attrs) </del> <ins> let fn_attrs = cx.tcx.codegen_fn_attrs(def_id); (check_and_apply_linkage(cx, &fn_attrs, ty, sym, Some(span)), attrs) </ins> } item => bug!("get_static: expected static, found {:?}", item) }; <ins> debug!("get_static: sym={} attrs={:?}", sym, attrs); </ins> for attr in attrs { if attr.check_name("thread_local") { llvm::set_thread_local_mode(g, cx.tls_model);
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: g } else { // FIXME(nagisa): perhaps the map of externs could be offloaded to llvm somehow? <del> // FIXME(nagisa): investigate whether it can be changed into define_global let g = declare::declare_global(cx, &sym, cx.layout_of(ty).llvm_type(cx)); </del> <ins> debug!("get_static: sym={} item_attr={:?}", sym, cx.tcx.item_attrs(def_id)); let attrs = cx.tcx.codegen_fn_attrs(def_id); let g = check_and_apply_linkage(cx, &attrs, ty, sym, None); </ins> // Thread-local statics in some other crate need to *always* be linked // against in a thread-local fashion, so we need to be sure to apply the // thread-local attribute locally if it was present remotely. If we // don't do this then linker errors can be generated where the linker // complains that one object files has a thread local version of the // symbol and another one doesn't. <del> for attr in cx.tcx.get_attrs(def_id).iter() { if attr.check_name("thread_local") { llvm::set_thread_local_mode(g, cx.tls_model); } </del> <ins> if attrs.flags.contains(CodegenFnAttrFlags::THREAD_LOCAL) { llvm::set_thread_local_mode(g, cx.tls_model); </ins> } if cx.use_dll_storage_attrs && !cx.tcx.is_foreign_item(def_id) { // This item is external but not foreign, i.e. it originates from an external Rust // crate. Since we don't know whether this crate will be linked dynamically or
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: g } <ins> fn check_and_apply_linkage<'tcx>( cx: &CodegenCx<'_, 'tcx>, attrs: &CodegenFnAttrs, ty: Ty<'tcx>, sym: LocalInternedString, span: Option<Span> ) -> ValueRef { let llty = cx.layout_of(ty).llvm_type(cx); if let Some(linkage) = attrs.linkage { debug!("get_static: sym={} linkage={:?}", sym, linkage); // If this is a static with a linkage specified, then we need to handle // it a little specially. The typesystem prevents things like &T and // extern "C" fn() from being non-null, so we can't just declare a // static and call it a day. Some linkages (like weak) will make it such // that the static actually has a null value. let llty2 = match ty.sty { ty::TyRawPtr(ref mt) => cx.layout_of(mt.ty).llvm_type(cx), _ => { if span.is_some() { cx.sess().span_fatal(span.unwrap(), "must have type `*const T` or `*mut T`") } else { bug!("must have type `*const T` or `*mut T`") } } }; unsafe { // Declare a symbol `foo` with the desired linkage. let g1 = declare::declare_global(cx, &sym, llty2); llvm::LLVMRustSetLinkage(g1, base::linkage_to_llvm(linkage)); // Declare an internal global `extern_with_linkage_foo` which // is initialized with the address of `foo`.  If `foo` is // discarded during linking (for example, if `foo` has weak // linkage and there are no definitions), then // `extern_with_linkage_foo` will instead be initialized to // zero. let mut real_name = "_rust_extern_with_linkage_".to_string(); real_name.push_str(&sym); let g2 = declare::define_global(cx, &real_name, llty).unwrap_or_else(||{ if span.is_some() { cx.sess().span_fatal( span.unwrap(), &format!("symbol `{}` is already defined", &sym) ) } else { bug!("symbol `{}` is already defined", &sym) } }); llvm::LLVMRustSetLinkage(g2, llvm::Linkage::InternalLinkage); llvm::LLVMSetInitializer(g2, g1); g2 } } else { // Generate an external declaration. // FIXME(nagisa): investigate whether it can be changed into define_global declare::declare_global(cx, &sym, llty) } } </ins> pub fn codegen_static<'a, 'tcx>( cx: &CodegenCx<'a, 'tcx>, def_id: DefId,
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: <ins> // Copyright 2018 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. #![crate_type = "rlib"] #![feature(linkage)] pub fn foo<T>() -> *const() { extern { #[linkage = "extern_weak"] static FOO: *const(); } unsafe { FOO } } </ins>