jiebi/CodeConvo huggingface dataset:
Code change:
//! } //! //! // This function wants to log its parameter out prior to doing work with it. <del> //! fn do_work<T: Show>(value: &T) { </del> <ins> //! fn do_work<T: Show+'static>(value: &T) { </ins> //!     log(value); //!     // ...do some other work //! }

Related discussion:
text: Example: This should be fixed by code in .
Nominating for 1.0, P-backcompat-lang.
Assigning 1.0, P-backcompat-lang
Code change:
None => return DummyResult::any(sp), }; // The file will be added to the code map by the parser <del> let file = cx.resolve_path(file, sp); </del> <ins> let file = match cx.resolve_path(file, sp) { Ok(f) => f, Err(mut err) => { err.emit(); return DummyResult::any(sp); }, }; </ins> let directory_ownership = DirectoryOwnership::Owned { relative: None }; let p = parse::new_sub_parser_from_file(cx.parse_sess(), &file, directory_ownership, None, sp);

Related discussion:
text: to reproduce the fault this can be used: will result in this ICE: thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', note: Run with RUSTBACKTRACE=1 environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.36.0 ( 2019-07-03) running on x86_64-unknown-linux-gnu the question is what is the path that shall be used when the code is from stdin maybe some temp file name in the currrent working dir.
This ICE also occurs when using and , which makes sense as they use the same mechanism under the hood (, , meaning it also .
While poking at this I also noticed that items are silently ignored, and filed .
Code change:
ARCH=$1 LIB_ARCH=$2 APT_ARCH=$3 <ins> MANUFACTURER=$4 </ins> BINUTILS=2.28.1 GCC=6.5.0 <del> # Choose correct target based on the $ARCH case "$ARCH" in x86_64) TARGET=x86_64-pc-solaris2.10 ;; sparcv9) TARGET=sparcv9-sun-solaris2.10 ;; *) printf 'ERROR: unknown architecture: %sn' "$ARCH" exit 1 esac </del> <ins> TARGET=${ARCH}-${MANUFACTURER}-solaris2.10 </ins> # First up, build binutils mkdir binutils

Related discussion:
text: removed the alias of to , but as far as I can tell did not remove the target itself. After inquiring on Zulip, it was pointed out that the target was demoted to tier three, meaning builds are no longer provided. It appears this was done with no discussion, warning, or even a mention in the release notes. Given that the target hasn't been around for that long (I think? feel free to tell me I'm wrong), I think this change should be reverted. My CI unexpectedly failed after being unable to download the target, and the only solution that wouldn't involve a notable increase in complexity of the CI script is to outright remove the checks for Solaris/Illumos — a let loss for everyone. cc
I think my feeling right now is that we should likely re-enable the sun-solaris target alongside the pc-solaris, I don't think that should be a major problem for CI times or similar. I will see if we can do this in time for 1.52.1, but if it ends up being harder than expected, I think it's likely that either a) we'll push it out to a 1.52.2 release later in the cycle, or simply leave it to 1.53. For the time being, tagging as 1.53.
I will note that the change itself is fine, of course, it's the suddenness and unexpectedness of it that caught me by surprise.
I think it is likely true that we'll eventually drop the sun target, but it does seem like we should communicate that change better at least. Certainly the newly merged target tier policy suggests just that:
It is not clear to me what the impact of was. In particular, the produced target was not changed in , but I guess the target definition is sort of for pc... I think I am not sufficiently confident in moving in a particular direction here - and a full revert does not seem quite right either - so I will likely say this should be left for at least 1.52.2 or 1.53.0. cc as well, who reviewed
Removal of the older target was certainly not my intent; if that happened due to , I am sorry. Both and are there and both targets are usable when compiling with , but I guess that change to one of files might have resulted in artifacts necessary for no longer being available.
Code change:
ARCH=$1 LIB_ARCH=$2 APT_ARCH=$3 <ins> MANUFACTURER=$4 </ins> BINUTILS=2.28.1 GCC=6.5.0 <del> # Choose correct target based on the $ARCH case "$ARCH" in x86_64) TARGET=x86_64-pc-solaris2.10 ;; sparcv9) TARGET=sparcv9-sun-solaris2.10 ;; *) printf 'ERROR: unknown architecture: %sn' "$ARCH" exit 1 esac </del> <ins> TARGET=${ARCH}-${MANUFACTURER}-solaris2.10 </ins> # First up, build binutils mkdir binutils

Related discussion:
text: I created , which I believe should bring back the ability to the old target.
Reopening to track the illumos target work. I'm not sure it's a release blocker, but would like to not lose sight.
The remaining bug in this issue -- the change in the compiler used to build illumos to be based on a -pc- triple, not -sun- here is not a release blocker.
Realistically I don't think there's anything actionable here, so I'm going to go ahead and close this.
Code change:
<ins> #![crate_type = "lib"] #![feature(unnamed_fields)] #![allow(unused, incomplete_features)] enum K { M { _ : struct { field: u8 }, //~^ error: unnamed fields are not allowed outside of structs or unions //~| error: anonymous structs are not allowed outside of unnamed struct or union fields } } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected ADT to be an item', 'error: internal compiler error: expected ADT to be an item' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [adtdef] computing ADT definition for [adtdef] computing ADT definition for [typeof] computing type of [inferredoutlivescrate] computing the inferred outlives predicates for items in this crate [inferredoutlivesof] computing inferred outlives predicates of [predicatesdefinedon] computing predicates of [predicatesof] computing predicates of [collectmoditemtypes] collecting item types in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Oh, seems that more checks are needed to prevent unnamed fields from occurring in enums.
claim
Code change:
<ins> error[E0080]: it is undefined behavior to use this value --> $DIR/issue-79690.rs:29:1 | LL | const G: Fat = unsafe { Transmute { t: FOO }.u }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered read of part of a pointer at .1.<deref>.size.foo | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

Related discussion:
text: <!-- 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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in .
Code change:
<ins> error[E0080]: it is undefined behavior to use this value --> $DIR/issue-79690.rs:29:1 | LL | const G: Fat = unsafe { Transmute { t: FOO }.u }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered read of part of a pointer at .1.<deref>.size.foo | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

Related discussion:
text: Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .
Code change:
&format!("comparison of `{}`", cx.ty_to_string(rhs_t))[], StrEqFnLangItem); <del> callee::trans_lang_call(cx, did, &[lhs, rhs], None, debug_loc) </del> <ins> let t = ty::mk_str_slice(cx.tcx(), cx.tcx().mk_region(ty::ReStatic), ast::MutImmutable); // The comparison function gets the slices by value, so we have to make copies here. Even // if the function doesn't write through the pointer, things like lifetime intrinsics // require that we do this properly let lhs_arg = alloc_ty(cx, t, "lhs"); let rhs_arg = alloc_ty(cx, t, "rhs"); memcpy_ty(cx, lhs_arg, lhs, t); memcpy_ty(cx, rhs_arg, rhs, t); let res = callee::trans_lang_call(cx, did, &[lhs_arg, rhs_arg], None, debug_loc); call_lifetime_end(res.bcx, lhs_arg); call_lifetime_end(res.bcx, rhs_arg); res </ins> } let _icx = push_ctxt("compare_values");

Related discussion:
text: Hi, The rust optimiser or some other component is not behaving correctly resulting in wrong results. I have produced a small example here : This was reproduced on Mac yosemite: cargo 0.0.1-pre-nightly ( 2015-01-30 02:47:30 +0000) rustc 1.0.0-nightly ( 2015-02-03 14:56:32 +0000) and centos7 x64, rustc 1.0.0-nightly ( 2015-02-05 23:14:28 +0000) Please let me know if you need any more details.
Reduced test case: This segfaults with = 2 (on Linux x86-64, )
This goes back to at least 0.12 - though it prints garbage values instead of segfaulting. 0.11 seems unaffected.
I've done some hacky . I'm not seeing the original data in the IR. cc Is this another memcpy metadata bug? Or a lifetime intrinsic issue. EDIT: turns out , which is used here, calls on its arguments, as if it was certain they were temporaries that didn't outlive the call (which is wrong, in this case). Not sure if needs to create a temporary for the value it's trying to compare with a constant, or the lifetime intrinsic calls shouldn't be emitted for .
This has two parts. When I extended rustc to emit lifetime intrinsics, I chose to put a call to at the end of functions to mark arguments as dead that are passed by value on the stack. This allows LLVM to remove dead stores at the end of functions that it normally can't remove. This works because normally, the caller makes a copy of the value it passes in. Now, the call that match generates to compare the strings is to , which accepts two slices by-value, and slices are large enough to be passed on the stack. Thus, calls to are emitted. But, the call the match generates does not actually make copies of the slices, but passes in pointers to the original slices. That means that the call marks the original alloca as dead, and then things fall apart. Question: Do we want to drop the call for by-value on-stack arguments, or fix the call to eqslice to make copies? cc
just-a-bug; P-high, not 1.0 milestone.
Code change:
<ins> // Regression test for ICE #130012 // Checks that we do not ICE while reporting // lifetime mistmatch error trait Fun { type Assoc; } trait MyTrait: for<'a> Fun<Assoc = &'a ()> {} //~^ ERROR binding for associated type `Assoc` references lifetime `'a`, which does not appear in the trait input types //~| ERROR binding for associated type `Assoc` references lifetime `'a`, which does not appear in the trait input types //~| ERROR binding for associated type `Assoc` references lifetime `'a`, which does not appear in the trait input types impl<F: for<'b> Fun<Assoc = &'b ()>> MyTrait for F {} //~^ ERROR binding for associated type `Assoc` references lifetime `'b`, which does not appear in the trait input types //~| ERROR mismatched types fn main() {} </ins>

Related discussion:
text: : current nightly <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This did not used to ICE prior to The PR is in nightly-2024-05-12 and Rust 1.80. The diagnostic from nightly-2024-05-11 before that PR is:
Code change:
<ins> #![allow(unused)] fn main() { let _foo = b'hello0'; //~^ ERROR character literal may only contain one codepoint //~| HELP if you meant to write a byte string literal, use double quotes let _bar = 'hello'; //~^ ERROR character literal may only contain one codepoint //~| HELP if you meant to write a `str` literal, use double quotes } </ins>

Related discussion:
text: When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!
Code change:
pub fn prepend(&mut self, line: usize, string: &str, style: Style) { self.ensure_lines(line); <del> let string_len = string.len(); </del> <ins> let string_len = string.chars().count(); </ins> // Push the old content over to make room for new content for _ in 0..string_len {

Related discussion:
text: Consider the following rust source (in ): It is obvious that it has syntax error. It also seems obvious that the generated error shouldn't depend on name of file except noting the name of file. However, it doesn't happen in practice: Note extra spaces after . Rust version (although it is not strictly relevant, see below): The core issue lies in the . The idea of the code is to make enough space in the beginning of line (filled with spaces) and then overwrite it character by character. However, in order to estimate the required space, which is wrong since in Rust can contain non-ASCII which require more than one byte for storage and keeps lines in s. It means that this isuue reveals itself only when a non-ASCII string is passed as an argument — and that's exactly what's happening in  under very specific circumstances: when processing a primary file, when is set (i. e. ) and when_ name of the primary file happens to have a non-ASCII name. The errorneous code for was introduced in . This bug landed in stable . The obvious fix is to change the line in into cc
I want to raise a question: is it really an issue worth fixing? It fires under very specific circumstances and the fix makes slower for every case, not only these specific ones.
I believe so.
Code change:
return None; } } <del> Some(i) </del> <ins> if lines.is_empty() { None } else { Some(lines[0][..i].into()) } </ins> } let data_s = data.as_str();

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
<ins> #![feature(prelude_import)] #![no_std] //@ check-pass //@ aux-build: another-proc-macro.rs //@ compile-flags: -Zunpretty=expanded #![feature(derive_smart_pointer)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; #[macro_use] extern crate another_proc_macro; use another_proc_macro::{pointee, AnotherMacro}; #[repr(transparent)] pub struct Ptr<'a, #[pointee] T: ?Sized> { data: &'a mut T, } #[automatically_derived] impl<'a, T: ?Sized + ::core::marker::Unsize<__S>, __S: ?Sized> ::core::ops::DispatchFromDyn<Ptr<'a, __S>> for Ptr<'a, T> { } #[automatically_derived] impl<'a, T: ?Sized + ::core::marker::Unsize<__S>, __S: ?Sized> ::core::ops::CoerceUnsized<Ptr<'a, __S>> for Ptr<'a, T> { } const _: () = { const POINTEE_MACRO_ATTR_DERIVED: () = (); }; #[pointee] struct MyStruct; const _: () = { const ANOTHER_MACRO_DERIVED: () = (); }; fn main() {} </ins>

Related discussion:
text: https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
} alloc0 (static: FOO, size: 8, align: 8) { <del> ╾───────alloc3────────╼                         │ ╾──────╼ </del> <ins> ╾───────alloc9────────╼                         │ ╾──────╼ </ins> } <del> alloc3 (size: 180, align: 1) { </del> <ins> alloc9 (size: 180, align: 1) { </ins> 0x00 │ ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab │ ................ 0x10 │ ab ab ab ab ab ab ab ab ab ab ab ab ╾──alloc4── │ ............╾─── 0x20 │ ──────────╼ 01 ef cd ab 00 00 00 00 00 00 00 00 │ ───╼............

Related discussion:
text: This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix
Code change:
<del> use crate::spec::{LinkerFlavor, PanicStrategy, Target, TargetResult}; </del> <ins> use crate::spec::{LinkerFlavor, Target, TargetResult}; </ins> pub fn target() -> TargetResult { let mut base = super::windows_uwp_msvc_base::opts(); base.max_atomic_width = Some(64); base.has_elf_tls = true; <del> // FIXME: this shouldn't be panic=abort, it should be panic=unwind base.panic_strategy = PanicStrategy::Abort; </del> Ok(Target { llvm_target: "aarch64-pc-windows-msvc".to_string(), target_endian: "little".to_string(),

Related discussion:
text: The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.