jiebi/CodeConvo huggingface dataset:
Code change:
``` "##, <del> //NB: not currently reachable E0247: r##" This error indicates an attempt to use a module name where a type is expected. For example: ``` mod MyMod { mod MySubMod { } } fn do_something(x: MyMod::MySubMod) { } ``` In this example, we're attempting to take a parameter of type `MyMod::MySubMod` in the do_something function. This is not legal: `MyMod::MySubMod` is a module name, not a type. "##, </del> E0248: r##" This error indicates an attempt to use a value where a type is expected. For example:

Related discussion:
text: rustc crashes when compiling the following source code. I expect this to compile or report error. Instead the compiler crashed.
Reduced testcase:
This also causes an ICE with the latest nightly:
Any update on the issue. Please let me know if you need more information. Thanks
Code change:
return; } <ins> let self_contained_linker = sess.opts.cg.link_self_contained.linker(); // FIXME: some targets default to using `lld`, but users can only override the linker on the CLI // and cannot yet select the precise linker flavor to opt out of that. See for example issue // #113597 for the `thumbv6m-none-eabi` target: a driver is used, and its default linker // conflicts with the target's flavor, causing unexpected arguments being passed. // // Until the new `LinkerFlavor`-like CLI options are stabilized, we only adopt MCP510's behavior // if its dedicated unstable CLI flags are used, to keep the current sub-optimal stable // behavior. let using_mcp510 = self_contained_linker || sess.opts.cg.linker_flavor.is_some_and(|f| f.is_unstable()); if !using_mcp510 && !unstable_use_lld { return; } </ins> // 1. Implement the "self-contained" part of this feature by adding rustc distribution //    directories to the tool's search path. <del> let self_contained_linker = sess.opts.cg.link_self_contained.linker() || unstable_use_lld; if self_contained_linker { </del> <ins> if self_contained_linker || unstable_use_lld { </ins> for path in sess.get_tools_search_paths(false) { cmd.arg({ let mut arg = OsString::from("-B");

Related discussion:
text: See also , where I set the default target for bare-metal SPARC to be gcc, precisely because the default libraries it links in are so useful - they include not only the start-up code (no idea how that works, didn't need to find out) but also a C library for talking to the stdout of a popular SPARC CPU emulator. So, yeah, GCC is a really useful linker driver in some scenarios and we don't want to stop that from working.
Thanks for the information, it's very helpful. The good news is that using GCC as a linker is still working . In the future where we switch to lld, maybe rustc will also need an explicit linker flavor here, to make sure the flavor it guesses actually matches your expectations. But that's a topic for another day/stabilization: in the more immediate future, things will return to normal for the target and 's tests in a day or two.
Thank you! Just to come back to this point: I was under the impression that Arm Ltd were maintaining the targets. However, they don't appear to have the platform-support documentation that is required for more recently targets. Maybe that could be addressed.
This is now on beta, reopening to track backport.
Pursuant to your concern I have opened to summarize the issue that affects indeed all our tier 2 targets.
The backport of has landed on beta in We can close this issue as fixed.
Code change:
.next() .map_or(false, |c| c.is_ascii_uppercase()) { <del> (format!("use of undeclared type `{}`", ident), None) </del> <ins> // Check whether the name refers to an item in the value namespace. let suggestion = if ribs.is_some() { let match_span = match self.resolve_ident_in_lexical_scope( ident, ValueNS, parent_scope, None, path_span, &ribs.unwrap()[ValueNS], ) { // Name matches a local variable. For example: // ``` // fn f() { //     let Foo: &str = ""; //     println!("{}", Foo::Bar); // Name refers to local //                               // variable `Foo`. // } // ``` Some(LexicalScopeBinding::Res(Res::Local(id))) => { Some(*self.pat_span_map.get(&id).unwrap()) } // Name matches item from a local name binding // created by `use` declaration. For example: // ``` // pub Foo: &str = ""; // // mod submod { //     use super::Foo; //     println!("{}", Foo::Bar); // Name refers to local //                               // binding `Foo`. // } // ``` Some(LexicalScopeBinding::Item(name_binding)) => { Some(name_binding.span) } _ => None, }; if let Some(span) = match_span { Some(( vec![(span, String::from(""))], format!("`{}` is defined here, but is not a type", ident), Applicability::MaybeIncorrect, )) } else { None } } else { None }; (format!("use of undeclared type `{}`", ident), suggestion) </ins> } else { (format!("use of undeclared crate or module `{}`", ident), None) }

Related discussion:
text: The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim
Code change:
<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that we don't crash when printing inherent projections in diagnostics. pub struct Carrier<'a>(&'a ()); pub type User = for<'b> fn(Carrier<'b>::Focus<i32>); impl<'a> Carrier<'a> { pub type Focus<T> = &'a mut User; //~ ERROR overflow evaluating associated type } 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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim
Code change:
<ins> warning: the feature `lazy_type_alias` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/alias-bounds-when-not-wf.rs:3:12 | LL | #![feature(lazy_type_alias)] |            ^^^^^^^^^^^^^^^ | = note: see issue #112792 <https://github.com/rust-lang/rust/issues/112792> for more information = note: `#[warn(incomplete_features)]` on by default error: the type `W<A<usize>>` is not well-formed --> $DIR/alias-bounds-when-not-wf.rs:16:13 | LL | fn hello(_: W<A<usize>>) {} |             ^^^^^^^^^^^ error: aborting due to 1 previous error; 1 warning emitted </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc
Code change:
use std::path::{Path, PathBuf}; use std::process::Command; <del> use build_helper::ci::CiEnv; </del> use tracing::*; use crate::common::{Config, Debugger, FailMode, Mode, PassMode};

Related discussion:
text: I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using Instead, this happened: <!-- 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 --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that.
Code change:
use std::path::{Path, PathBuf}; use std::process::Command; <del> use build_helper::ci::CiEnv; </del> use tracing::*; use crate::common::{Config, Debugger, FailMode, Mode, PassMode};

Related discussion:
text: claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:
Code change:
<ins> pub struct Option; impl Option { pub fn unwrap(self) {} } mod macros { use crate::Option; /// [`Option::unwrap`] #[macro_export] macro_rules! print { () => () } } mod structs { use crate::Option; /// [`Option::unwrap`] pub struct Print; } pub use structs::Print; </ins>

Related discussion:
text: I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- 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<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.
Code change:
<ins> // check-pass // edition:2021 use std::rc::Rc; // Test that we restrict precision when moving not-`Copy` types, if any of the parent paths // implement `Drop`. This is to ensure that we don't move out of a type that implements Drop. pub fn test1() { struct Foo(Rc<i32>); impl Drop for Foo { fn drop(self: &mut Foo) {} } let f = Foo(Rc::new(1)); let x = move || { println!("{:?}", f.0); }; x(); } // Test that we don't restrict precision when moving `Copy` types(i.e. when copying), // even if any of the parent paths implement `Drop`. pub fn test2() { struct Character { hp: u32, name: String, } impl Drop for Character { fn drop(&mut self) {} } let character = Character { hp: 100, name: format!("A") }; let c = move || { println!("{}", character.hp) }; c(); println!("{}", character.name); } fn main() {} </ins>

Related discussion:
text: I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Code change:
<ins> error[E0428]: the name `f` is defined multiple times --> $DIR/test-compile-fail1.rs:8:1 | 6 | pub fn f() {} | ---------- previous definition of the value `f` here 7 | 8 | pub fn f() {} | ^^^^^^^^^^ `f` redefined here | = note: `f` must be defined only once in the value namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

Related discussion:
text: I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.
Code change:
<ins> error[E0428]: the name `f` is defined multiple times --> $DIR/test-compile-fail1.rs:8:1 | 6 | pub fn f() {} | ---------- previous definition of the value `f` here 7 | 8 | pub fn f() {} | ^^^^^^^^^^ `f` redefined here | = note: `f` must be defined only once in the value namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

Related discussion:
text: I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
Code change:
target_val!(data_layout); target_option_val!(is_builtin); <del> target_option_val!(endian, "target_endian"); target_option_val!(c_int_width, "target_c_int_width"); </del> <ins> target_option_val!(endian, "target-endian"); target_option_val!(c_int_width, "target-c-int-width"); </ins> target_option_val!(os); target_option_val!(env); target_option_val!(vendor);

Related discussion:
text: Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)
Code change:
infer::IfExpression(_) => { format!("if and else have compatible types") } <ins> infer::IfExpressionWithNoElse(_) => { format!("if may be missing an else clause") } </ins> }; match self.values_str(&trace.values) {

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:
Code change:
-include ../tools.mk <del> # This test makes sure that indirect call promotion is performed. The test # programs calls the same function a thousand times through a function pointer. # Only PGO data provides the information that it actually always is the same # function. We verify that the indirect call promotion pass inserts a check # whether it can make a direct call instead of the indirect call. # LLVM doesn't support instrumenting binaries that use SEH: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMMON_FLAGS=-Cpanic=abort endif </del> all: # We don't compile `opaque` with either optimizations or instrumentation. # We don't compile `opaque` with either optimizations or instrumentation.

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?