jiebi/CodeConvo huggingface dataset:
Code change:
COMPILE_FLAGS=-g -Cprofile-generate="$(TMPDIR)" <del> # LLVM doesn't yet support instrumenting binaries that use unwinding on MSVC: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMPILE_FLAGS+= -Cpanic=abort endif </del> all: $(RUSTC) $(COMPILE_FLAGS) test.rs $(call RUN,test) || exit 1

Related discussion:
text: LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?
Code change:
offset: Size, ) -> Self { let alloc_align = alloc.inner().align; <del> assert_eq!(alloc_align, layout.align.abi); </del> <ins> assert!(alloc_align >= layout.align.abi); </ins> let read_scalar = |start, size, s: abi::Scalar, ty| { match alloc.0.read_scalar(

Related discussion:
text: Error: That's this: The GVN MIR diff is this: searched nightlies: from nightly-2023-06-01 to nightly-2023-11-08 regressed nightly: nightly-2023-10-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This issue is a bit old but I've now minimized the reproducer, it's in the description. the assertion that's failing here looks to me like it is simply too picky, and it should be checking if the alignment of the allocation is the alignment of the type we're reading from it, instead of exactly equal. Do you agree that this is just a too-picky assertion?
I agree the assertion is just too picky. I expect the subtlety of needing to pass the larger alignment for the llvm constant.
I can't figure out what you mean here. What LLVM constant? Why is there subtelty? Maybe I just don't understand what's going on with GVN here, I'm assuming that GVN has merged two constants together so that we're now loading part of a more-aligned constant to get a less-aligned one. Is that wrong?
I mean, this is codegen code. It creates a constant for llvm. That constant has some alignment. We need to pick the right one, between the lhs and rhs of the assert.
Where are we picking an alignment? Is it down here?
smaller repro: <!-- ICE: Rustc '-Zmir-opt-level=5 -Cdebuginfo=2 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: --
I don't really know.
Code change:
offset: Size, ) -> Self { let alloc_align = alloc.inner().align; <del> assert_eq!(alloc_align, layout.align.abi); </del> <ins> assert!(alloc_align >= layout.align.abi); </ins> let read_scalar = |start, size, s: abi::Scalar, ty| { match alloc.0.read_scalar(

Related discussion:
text: TBH, the simplest solution is a codegen test, and check that the generated constant has the right over-alignment.
I don't have confidence in my ability to do that, so I think it would unblock you faster if you took this issue. I feel like just this diff is a fix for this ICE: But I don't understand why the assertion was exact in the first place, or what the hazard would be from over-aligning the allocation.
Code change:
Ok(true) } ty::Float(_) | ty::Int(_) | ty::Uint(_) => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = try_validation!( self.ecx.read_scalar(value), self.path, err_unsup!(ReadPointerAsBytes) => { "read of part of a pointer" }, ); </ins> // NOTE: Keep this in sync with the array optimization for int/float // types below! if self.ctfe_mode.is_some() {

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:
Ok(true) } ty::Float(_) | ty::Int(_) | ty::Uint(_) => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = try_validation!( self.ecx.read_scalar(value), self.path, err_unsup!(ReadPointerAsBytes) => { "read of part of a pointer" }, ); </ins> // NOTE: Keep this in sync with the array optimization for int/float // types below! if self.ctfe_mode.is_some() {

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:
use middle::typeck::astconv::ast_ty_to_ty; use middle::typeck::infer; use middle::{typeck, ty, def, pat_util, stability}; <ins> use middle::const_eval::{eval_const_expr_partial, const_int, const_uint}; </ins> use util::ppaux::{ty_to_string}; use util::nodemap::NodeSet; use lint::{Context, LintPass, LintArray};

Related discussion:
text: Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!
Code change:
pub fn takes_non_exhaustive(_: NonExhaustiveEnum) { let _closure = |_: NonExhaustiveEnum| {}; } <ins> // ICE #117033 enum Void {} #[deny(non_exhaustive_omitted_patterns)] pub fn void(v: Void) -> ! { match v {} } </ins>

Related discussion:
text: File: auto-reduced (treereduce-rust): original: 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
What is intriguing is that the transmute doesn't fail, as it is a transmute from a 1ZST to a Never-like type, which has no representations. This code is definitely unsound, but I guess this is already a known thing.
Regression in cc
:facepalm: Oops, fix here: Good catch!
Code change:
<ins> error[E0433]: failed to resolve: use of undeclared crate or module `should_panic` --> $DIR/check-builtin-attr-ice.rs:43:7 | LL |     #[should_panic::skip] |       ^^^^^^^^^^^^ use of undeclared crate or module `should_panic` error[E0433]: failed to resolve: use of undeclared crate or module `should_panic` --> $DIR/check-builtin-attr-ice.rs:47:7 | LL |     #[should_panic::a::b::c] |       ^^^^^^^^^^^^ use of undeclared crate or module `should_panic` error[E0433]: failed to resolve: use of undeclared crate or module `deny` --> $DIR/check-builtin-attr-ice.rs:55:7 | LL |     #[deny::skip] |       ^^^^ use of undeclared crate or module `deny` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0433`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ', 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ' File: --auto-reduced (treereduce-rust): original: 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: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
there are a bunch more which probably all follow the pattern... 2 "errorreason": "error: internal compiler error: builtin attribute "allow" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cfgattr" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "cfg" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cmsenonsecureentry" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "collapsedebuginfo" not handled by ", 6 "errorreason": "error: internal compiler error: builtin attribute "deny" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "doc" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "inline" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "macroexport" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "optimize" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "procmacroderive" not handled by ", 14 "errorreason": "error: internal compiler error: builtin attribute "procmacro" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "shouldpanic" not handled by ",
cc
Taking a look
Problem is the previous match falls through to the fallback case for etc. because it has 1 segments ... and then since et al. is a attribute, it triggers the ICE.
I have a candidate fix locally, doing some more testing
Opened as a candidate fix.
Code change:
} } <del> match r.read(&mut g.buf[g.len..]) { Ok(0) => { ret = Ok(g.len - start_len); break; </del> <ins> let buf = &mut g.buf[g.len..]; match r.read(buf) { Ok(0) => return Ok(g.len - start_len), Ok(n) => { // We can't allow bogus values from read. If it is too large, the returned vec could have its length // set past its capacity, or if it overflows the vec could be shortened which could create an invalid // string if this is called via read_to_string. assert!(n <= buf.len()); g.len += n; </ins> } <del> Ok(n) => g.len += n, </del> Err(ref e) if e.kind() == ErrorKind::Interrupted => {} <del> Err(e) => { ret = Err(e); break; } </del> <ins> Err(e) => return Err(e), </ins> } } <del> ret </del> } pub(crate) fn default_read_vectored<F>(read: F, bufs: &mut [IoSliceMut<'_>]) -> Result<usize>

Related discussion:
text: At line 393, the guard object's field is incremented by the value returned from a read implementation. If a questionable returns a value larger than the buffer size, it will take that value and set the length of the vector over the boundary. This bug is reachable from and . Here is a that demonstrates the bug. It segfaults with .
This is definitely broken - nice find. A simple fix would be to just add an in the drop impl: You can still get weird behavior in readtoendwithreservation, but it should be memory safe and it seems best to avoid a bunch of extra logic in the main loop.
It looks like the bug was introduced in
Assigning as and removing .
Code change:
<ins> // Copyright 2017 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. #![feature(rustc_attrs)] #![deny(non_snake_case)] #[no_mangle] pub extern "C" fn SparklingGenerationForeignFunctionInterface() {} #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Related discussion:
text: Since the function is tagged the exact name presumably has to exactly match something that another system is expecting, which may not be snake case. For example, JNI bindings will look something like
Modifying lints requires an RFC now, as it can impact a LOT of code.
(By modifying I mean "major changes" not bugfixes)
Hm, while I think new lints definitely want an RFC, modifications to existing ones can probably go through the lang team's nomination process, leading to either an immediate decision or request for RFC.
I'm fine with that, just following (what I thought was) procedure. :smile:
Code change:
test(parse(""), None); { <del> let build_dir = if cfg!(windows) { Some("C:tmp") } else { Some("/tmp") }; test(parse("build.build-dir = "/tmp""), build_dir); </del> <ins> let build_dir = if cfg!(windows) { "C:tmp" } else { "/tmp" }; test(parse(&format!("build.build-dir = '{build_dir}'")), Some(build_dir)); </ins> } }

Related discussion:
text: On native Windows:
This looks sus: That's a which is an absolute Unix path. On Windows it will be interpreted relative to the root of the current directory. For example, if your current directory is then it'll be . (Also it'd be nice to use raw strings here because the is confusing in the context of paths)
Code change:
<ins> // check-pass // check that `deref_into_dyn_supertrait` doesn't cause ICE by eagerly converting // a cancelled lint #![allow(deref_into_dyn_supertrait)] trait Trait {} impl std::ops::Deref for dyn Trait + Send + Sync { type Target = dyn Trait; fn deref(&self) -> &Self::Target { self } } fn main() {} </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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- 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 label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve
Code change:
<del> A control-flow expression was used inside a const context. </del> <ins> An unsupported expression was used inside a const context. </ins> Erroneous code example:

Related discussion:
text: I have to use some sort of loop construct within a const function. does explain that loop constructs are at the moment not supported, but as I was trying out first and the compiler rejected it, it would have been helpful if the explanation would hint me towards working. I think the doc just needs a small update and I think the file to update is I tried this code: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
, , and are also allowed, but is not.
if it helps, the reason is forbidden but the others work is that uses and traits in const functions are still unstable (search for 'for loops' on https://rust-).
yeah, that's understandable. The confusion on my side was simply that I didn't know I was allowed to user other control flow constructs until somebody mentioned it on IRC I actually could.
Code change:
// error-pattern: too big for the current fn main() { <del> let fat : [u8, ..(1<<61)+(1<<31)] = [0, ..(1<<61)+(1<<31)]; </del> <ins> let fat : [u8, ..(1<<61)+(1<<31)] = [0, ..(1u64<<61) as uint +(1u64<<31) as uint]; </ins> }

Related discussion:
text: Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!
Code change:
| LL | fn d<const C: S>() {} |               ^ expected named lifetime parameter <del> | help: consider introducing a named lifetime parameter | LL | fn d<'a, const C: S<'a>>() {} |      +++           ++++ </del> error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/unusual-rib-combinations.rs:29:22

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
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
<del> Subproject commit 68ff8b19bc6705724d1e77a8dc17ffb8dfbbe26b </del> <ins> Subproject commit edd90473ec5ba29b9ae1ee706c982e7046a6e63e </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Code change:
IfExpression(a) => { format!("IfExpression({})", a.repr(tcx)) } <ins> IfExpressionWithNoElse(a) => { format!("IfExpressionWithNoElse({})", a.repr(tcx)) } </ins> } } }

Related discussion:
text: I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change: