jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error[E0425]: cannot find value `bogus` in this scope --> $DIR/issue-59134-1.rs:8:37 | LL |         const CONST: Self::MyType = bogus.field; |                                     ^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well
Code change:
} declare_lint! { <ins> /// The `function_item_references` lint detects function references that are /// formatted with [`fmt::Pointer`] or transmuted. /// /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html /// /// ### Example /// /// ```rust /// fn foo() { } /// /// fn main() { ///     println!("{:p}", &foo); /// } /// ``` /// /// {{produces}} /// /// ### Explanation /// /// Taking a reference to a function may be mistaken as a way to obtain a /// pointer to that function. This can give unexpected results when /// formatting the reference as a pointer or transmuting it. This lint is /// issued when function references are formatted as pointers, passed as /// arguments bound by [`fmt::Pointer`] or transmuted. pub FUNCTION_ITEM_REFERENCES, Warn, "suggest casting to a function pointer when attempting to take references to function items", } declare_lint! { </ins> /// The `uninhabited_static` lint detects uninhabited statics. /// /// ### Example

Related discussion:
text: I tried this code: I expected to see this happen: The compilation succeed or guide me to (1) cast the to with . (2) borrow the : . But in this case the addresses printed are the same (what?). Instead, this happened*: Cryptic error message: There is : . It took me minutes before I found the workaround. But it still surprised me. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This creates a reference-to-function-pointer (type ), a double indirection. So it is not what you want. The error could possibly be improved, and the entire situation documented better, but I think getting an error is expected here. is not a function pointer, it is an anonymous ) (of size 0) indicating exactly the function it was created from. This type coerces to a function pointer, but cannot know what type to coerce it to. Printing function pointers is easy (well, if they are not polymorphic via ), but printing these function singleton ZSTs is hard.
It might also be worth linting against .
helps with the docs. But to close this issue, it would probably make sense to write a lint against where is the name of a function. That should be a matter of adding a new in which checks all expressions for being . That path we can pass to to get a . Now we just need to check if that refers to a function: pass the to . At least I hope that makes sense, someone stop me if this is all wrong. ;)
I'd like to help write this lint. The default level for the lint should be right? claim
Yeah, feels like a reasonable start.
Nominated for lang team discussion. It seems we usually ask for lints to be approved before shipping them, so let's get that process started. sorry for this, I wasn't aware of this part of the process. You can still go ahead and implement this if you want, but depending on what the lang team decides, we should submit this lint to clippy instead of the compiler itself. That might require minor adjustments, but the main work you are putting in and the testcases will be useful either way.
Code change:
} declare_lint! { <ins> /// The `function_item_references` lint detects function references that are /// formatted with [`fmt::Pointer`] or transmuted. /// /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html /// /// ### Example /// /// ```rust /// fn foo() { } /// /// fn main() { ///     println!("{:p}", &foo); /// } /// ``` /// /// {{produces}} /// /// ### Explanation /// /// Taking a reference to a function may be mistaken as a way to obtain a /// pointer to that function. This can give unexpected results when /// formatting the reference as a pointer or transmuting it. This lint is /// issued when function references are formatted as pointers, passed as /// arguments bound by [`fmt::Pointer`] or transmuted. pub FUNCTION_ITEM_REFERENCES, Warn, "suggest casting to a function pointer when attempting to take references to function items", } declare_lint! { </ins> /// The `uninhabited_static` lint detects uninhabited statics. /// /// ### Example

Related discussion:
text: :)
As a point of interest, this would have been extremely useful in helping debug a segfault in The original code used , not .
Without the cast, this should not compile as transmute checks that the sizes match. I assume what you describe happens when using , i.e., not just remove the but also add a .
Unfortunately I never committed the broken code so I'm not sure what I had originally ... the closest thing is which doesn't compile. Sorry for the noise.
no worries. I already have the lint implemented, but in that case I'll wait until they discuss to write the tests
I think should compile. That's no noise, it seems very relevant. :)
poll T-lang Should we add a lint for taking a reference to a fn?
Team member has asked teams: T-lang, for consensus on: [x] [x] [x] [ ] [x] [ ]
I think I agree here, but to confirm: this isn't actually about linting the taking of a reference to a place of type, but just about using on the voldemort-typed function name constants, right?
Yes.
Discussed in a (rather small) meeting today: Those present felt a lint would make sense. If somebody wanted to go ahead and try to author one, please feel free and nominate the resulting PR for discussion.
all right, so if you want to open a PR, everything is settled for that. :)
Code change:
/// If a file already exists in the source_map with the same id, that file is returned /// unmodified pub fn new_source_file(&self, filename: FileName, src: String) -> Lrc<SourceFile> { <ins> self.try_new_source_file(filename, src) .unwrap_or_else(|OffsetOverflowError| { eprintln!("fatal error: rustc does not support files larger than 4GB"); errors::FatalError.raise() }) } fn try_new_source_file( &self, filename: FileName, src: String ) -> Result<Lrc<SourceFile>, OffsetOverflowError> { </ins> let start_pos = self.next_start_pos(); // The path is used to determine the directory for loading submodules and

Related discussion:
text: I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened
Code change:
CONST_EVALUATABLE_UNCHECKED, INEFFECTIVE_UNSTABLE_TRAIT_IMPL, UNINHABITED_STATIC, <ins> FUNCTION_ITEM_REFERENCES, </ins> ] }

Related discussion:
text: I tried this code: I expected to see this happen: The compilation succeed or guide me to (1) cast the to with . (2) borrow the : . But in this case the addresses printed are the same (what?). Instead, this happened*: Cryptic error message: There is : . It took me minutes before I found the workaround. But it still surprised me. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This creates a reference-to-function-pointer (type ), a double indirection. So it is not what you want. The error could possibly be improved, and the entire situation documented better, but I think getting an error is expected here. is not a function pointer, it is an anonymous ) (of size 0) indicating exactly the function it was created from. This type coerces to a function pointer, but cannot know what type to coerce it to. Printing function pointers is easy (well, if they are not polymorphic via ), but printing these function singleton ZSTs is hard.
It might also be worth linting against .
helps with the docs. But to close this issue, it would probably make sense to write a lint against where is the name of a function. That should be a matter of adding a new in which checks all expressions for being . That path we can pass to to get a . Now we just need to check if that refers to a function: pass the to . At least I hope that makes sense, someone stop me if this is all wrong. ;)
I'd like to help write this lint. The default level for the lint should be right? claim
Yeah, feels like a reasonable start.
Nominated for lang team discussion. It seems we usually ask for lints to be approved before shipping them, so let's get that process started. sorry for this, I wasn't aware of this part of the process. You can still go ahead and implement this if you want, but depending on what the lang team decides, we should submit this lint to clippy instead of the compiler itself. That might require minor adjustments, but the main work you are putting in and the testcases will be useful either way.
Code change:
CONST_EVALUATABLE_UNCHECKED, INEFFECTIVE_UNSTABLE_TRAIT_IMPL, UNINHABITED_STATIC, <ins> FUNCTION_ITEM_REFERENCES, </ins> ] }

Related discussion:
text: :)
As a point of interest, this would have been extremely useful in helping debug a segfault in The original code used , not .
Without the cast, this should not compile as transmute checks that the sizes match. I assume what you describe happens when using , i.e., not just remove the but also add a .
Unfortunately I never committed the broken code so I'm not sure what I had originally ... the closest thing is which doesn't compile. Sorry for the noise.
no worries. I already have the lint implemented, but in that case I'll wait until they discuss to write the tests
I think should compile. That's no noise, it seems very relevant. :)
poll T-lang Should we add a lint for taking a reference to a fn?
Team member has asked teams: T-lang, for consensus on: [x] [x] [x] [ ] [x] [ ]
I think I agree here, but to confirm: this isn't actually about linting the taking of a reference to a place of type, but just about using on the voldemort-typed function name constants, right?
Yes.
Discussed in a (rather small) meeting today: Those present felt a lint would make sense. If somebody wanted to go ahead and try to author one, please feel free and nominate the resulting PR for discussion.
all right, so if you want to open a PR, everything is settled for that. :)
Code change:
/// f.read_to_string(&mut buf).unwrap(); /// assert_eq!(&buf, hello); /// ``` <del> #[unstable(feature = "seek_rewind", issue = "85149")] </del> <ins> #[stable(feature = "seek_rewind", since = "1.55.0")] </ins> fn rewind(&mut self) -> Result<()> { self.seek(SeekFrom::Start(0))?; Ok(())

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for the convenience method . [x] Implementation: [x] Final commenting period (FCP) [x] Stabilization PR: <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .
Code change:
/// f.read_to_string(&mut buf).unwrap(); /// assert_eq!(&buf, hello); /// ``` <del> #[unstable(feature = "seek_rewind", issue = "85149")] </del> <ins> #[stable(feature = "seek_rewind", since = "1.55.0")] </ins> fn rewind(&mut self) -> Result<()> { self.seek(SeekFrom::Start(0))?; Ok(())

Related discussion:
text: :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I missed it completely in nigthlies sadly, else I would have proposed it returns the of the old offset, because currently it cannot replace , only the form without assignement.
Code change:
def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

Related discussion:
text: I run cp ans then build && install and I get: $ build && install downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13rust-std-1.58.0-x8664-pc-windows- downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13rustc-1.58.0-x8664-pc-windows- downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13cargo-1.58.0-x8664-pc-windows- Building rustbuild error: failed to load manifest for workspace member Caused by: failed to read Caused by: The system cannot find the file specified. (os error 2) failed to run: G:rust-1.59.0rust-1.59.0buildx86_64-pc-windows-gnustage0bin build --manifest-path G:rust-1.59.0rust-1.59.0 Build completed unsuccessfully in 0:08:36
Can you say more about how you obtained and extracted the rust source? If you downloaded and extracted from , the directory should be there.
I downloaded the source from here: and the src/tools/rust-installer is there and is empty.
Ah, the tagged GitHub releases shouldn't be used. They do not include the git submodules. The link above is the one that should be used. Unfortunately we don't have the ability to disable GitHub releases, but we can probably add an error message to x.py if it can detect this scenario.
I did build && install and got $ build && install Building rustbuild Finished dev [unoptimized] target(s) in 1m 06s warning: creating symbolic link to failed with Incorrect function. (os error 1) Building stage0 std artifacts (x8664-pc-windows-gnu -x8664-pc-windows-gnu) Finished release [optimized] target(s) in 39.
Code change:
def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

Related discussion:
text: 65s Copying stage0 std from stage0 (x8664-pc-windows-gnu -x8664-pc-windows-gnu / x8664-pc-windows-gnu) Building LLVM for x8664-pc-windows-gnu running: "cmake" "G:rustc-1.59.0-srcrustc-1.59.0-srcsrc/llvm-project/llvm" "-G" "Ninja" "-DLLVMENABLEASSERTIONS=OFF" "-DLLVMENABLEPLUGINS=OFF" "-DLLVMTARGETSTOBUILD=AArch64;ARM;BPF;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86" "-DLLVMEXPERIMENTALTARGETSTOBUILD=AVR;M68k" "-DLLVMINCLUDEEXAMPLES=OFF" "-DLLVMINCLUDEDOCS=OFF" "-DLLVMINCLUDEBENCHMARKS=OFF" "-DLLVMINCLUDETESTS=OFF" "-DLLVMENABLETERMINFO=OFF" "-DLLVMENABLELIBEDIT=OFF" "-DLLVMENABLEBINDINGS=OFF" "-DLLVMENABLEZ3SOLVER=OFF" "-DLLVMPARALLELCOMPILEJOBS=4" "-DLLVMTARGETARCH=x8664" "-DLLVMDEFAULTTARGETTRIPLE=x8664-pc-windows-gnu" "-DLLVMINSTALLUTILS=ON" "-DLLVMENABLEZLIB=OFF" "-DLLVMENABLELIBXML2=OFF" "-DLLVMVERSIONSUFFIX=-rust-dev" "-DCMAKEINSTALLMESSAGE=LAZY" "-" "-" "-" "-DCMAKECFLAGS=-ffunction-sections -fdata-sections -m64" "-DCMAKECXXFLAGS=-ffunction-sections -fdata-sections -m64" "-DCMAKEINSTALLPREFIX=G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvm" "-DCMAKEASMFLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKEBUILDTYPE=Release" -- Could NOT find Backtrace (missing: BacktraceLIBRARY BacktraceINCLUDEDIR) -- Native target architecture is X86 -- Threads enabled. -- Doxygen disabled. -- Go bindings disabled.
Code change:
def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

Related discussion:
text: -- Ninja version: 1.10.2 -- Could NOT find OCaml (missing: OCAMLFIND OCAMLVERSION OCAMLSTDLIBPATH) -- OCaml bindings disabled. -- LLVM host triple: x8664-w64-windows-gnu -- LLVM default target triple: x8664-pc-windows-gnu -- LLVMHello ignored -- Loadable modules not supported on this platform. -- Targeting AArch64 -- Targeting ARM -- Targeting BPF -- Targeting Hexagon -- Targeting MSP430 -- Targeting Mips -- Targeting NVPTX -- Targeting PowerPC -- Targeting RISCV -- Targeting Sparc -- Targeting SystemZ -- Targeting WebAssembly -- Targeting X86 -- Targeting AVR -- Targeting M68k -- BugpointPasses ignored -- Loadable modules not supported on this platform. -- Configuring done -- Generating done -- Build files have been written to: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build running: "cmake" "--build" "." "--target" "install" "--config" "Release" "--" "-j" "4" [1/2594] Building FAILED: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows- /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-attrs -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.