# compiler

**URL:** https://internals.rust-lang.org/c/compiler/20.md?page=1

[Latest](https://internals.rust-lang.org/latest.md) · [Categories](https://internals.rust-lang.org/categories.md)

**Page:** 2

---

## [Make as\_raw\_handle() and similar functions unsafe in the next edition](https://internals.rust-lang.org/t/make-as-raw-handle-and-similar-functions-unsafe-in-the-next-edition/23784)

<div class="topic-metadata">

**Author:** [@arnabanimesh](https://internals.rust-lang.org/u/arnabanimesh)\
**Replies:** 3\
**Last updated:** [December 8, 2025, 3:56am UTC](https://internals.rust-lang.org/t/make-as-raw-handle-and-similar-functions-unsafe-in-the-next-edition/23784 "2025-12-08T03:56:39Z")

</div>

There are still some unsafe functions which are not yet marked as unsafe. Maybe we could mark them as such in the next edition.

---

## [Question about const evaluation](https://internals.rust-lang.org/t/question-about-const-evaluation/23790)

<div class="topic-metadata">

**Author:** [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia)\
**Replies:** 5\
**Last updated:** [December 3, 2025, 5:42pm UTC](https://internals.rust-lang.org/t/question-about-const-evaluation/23790 "2025-12-03T17:42:20Z")

</div>

There is that issue for generic const expressions that some consts may fail to compute. Solution I see everywhere is for user to make a bound that constant evaluated successfully. Example of failure may be an overflow wh…

---

## [Bad optimization for continuous memory access with redundant early check](https://internals.rust-lang.org/t/bad-optimization-for-continuous-memory-access-with-redundant-early-check/23771)

<div class="topic-metadata">

**Author:** [@Evian-Zhang](https://internals.rust-lang.org/u/Evian-Zhang)\
**Replies:** 7\
**Last updated:** [November 30, 2025, 9:21am UTC](https://internals.rust-lang.org/t/bad-optimization-for-continuous-memory-access-with-redundant-early-check/23771 "2025-11-30T09:21:48Z")

</div>

Goal: Get a u64 from continuous 8 elements in a &\[u8\], and check its value (All following codes can be checked in playground, with additionally worse u128 examples available) Good one To avoid unaligned access, I use t…

---

## [Distributing x86-64 tier 1 with host tools v1–3 each](https://internals.rust-lang.org/t/distributing-x86-64-tier-1-with-host-tools-v1-3-each/23599)

<div class="topic-metadata">

**Author:** [@miikkas](https://internals.rust-lang.org/u/miikkas)\
**Replies:** 19\
**Last updated:** [November 9, 2025, 4:57pm UTC](https://internals.rust-lang.org/t/distributing-x86-64-tier-1-with-host-tools-v1-3-each/23599 "2025-11-09T16:57:33Z")

</div>

As a soft roll-out for distributing newer-than-v1 x86-64 tier 1 tools, the list could be extended by providing v1, v2, and v3 of each of the existing targets. How? First of all, the target used for building the compiler…

---

## [Changing the default x86-64 compilation target to v2 or v3](https://internals.rust-lang.org/t/changing-the-default-x86-64-compilation-target-to-v2-or-v3/21889)

<div class="topic-metadata">

**Author:** [@vlovich](https://internals.rust-lang.org/u/vlovich)\
**Replies:** 70\
**Last updated:** [November 4, 2025, 5:39pm UTC](https://internals.rust-lang.org/t/changing-the-default-x86-64-compilation-target-to-v2-or-v3/21889 "2025-11-04T17:39:06Z")

</div>

I found this issue about changing the architecture for the compiler itself, but I've not found anything about changing the default target for things built by the compiler to newer standards. This should have fewer of the…

---

## [\[algorithm\] new float/double to string algorithm](https://internals.rust-lang.org/t/algorithm-new-float-double-to-string-algorithm/23670)

<div class="topic-metadata">

**Author:** [@xjb714](https://internals.rust-lang.org/u/xjb714)\
**Replies:** 7\
**Last updated:** [October 31, 2025, 6:53pm UTC](https://internals.rust-lang.org/t/algorithm-new-float-double-to-string-algorithm/23670 "2025-10-31T18:53:32Z")

</div>

xjb714/xjb: fast float to string algorithm. This is my work. Welcome everyone to learn about and use it.

---

## [Debug info for copy/move operations](https://internals.rust-lang.org/t/debug-info-for-copy-move-operations/23557)

<div class="topic-metadata">

**Author:** [@jsgf](https://internals.rust-lang.org/u/jsgf)\
**Replies:** 10\
**Last updated:** [October 17, 2025, 6:42pm UTC](https://internals.rust-lang.org/t/debug-info-for-copy-move-operations/23557 "2025-10-17T18:42:03Z")

</div>

At the moment, it can be very hard to identify compiler-generated copy/move operations in the output code. It's possible to see a sequence of load/store operations, or calls to memcpy, but you can't tell its a copy/move …

---

## [Where is mir-opt-level=2 (or higher) actually applied in rustc?](https://internals.rust-lang.org/t/where-is-mir-opt-level-2-or-higher-actually-applied-in-rustc/23619)

<div class="topic-metadata">

**Author:** [@DannyLumos](https://internals.rust-lang.org/u/DannyLumos)\
**Replies:** 2\
**Last updated:** [October 17, 2025, 1:59pm UTC](https://internals.rust-lang.org/t/where-is-mir-opt-level-2-or-higher-actually-applied-in-rustc/23619 "2025-10-17T13:59:53Z")

</div>

Hi all, While reading the rustc 1.90 source, I noticed that mir-opt-level is defined as: pub fn mir\_opt\_level(&self) -\> usize { self.opts.unstable\_opts.mir\_opt\_level .unwrap\_or\_else(|| if self.opts.optimize…

---

## [Idea: Easier cross lang LTO?](https://internals.rust-lang.org/t/idea-easier-cross-lang-lto/23568)

<div class="topic-metadata">

**Author:** [@NobodyXu](https://internals.rust-lang.org/u/NobodyXu)\
**Replies:** 8\
**Last updated:** [October 16, 2025, 10:59pm UTC](https://internals.rust-lang.org/t/idea-easier-cross-lang-lto/23568 "2025-10-16T22:59:49Z")

</div>

The current cross lang LTO using linker-plugin-lto doesn't work well with cross compilation tool such as cargo-zigbuild Why can't rustc package external libraries with their corresponding rust crate together, mixing the…

---

## [Allow panic! macro to take static strings as only argument](https://internals.rust-lang.org/t/allow-panic-macro-to-take-static-strings-as-only-argument/23613)

<div class="topic-metadata">

**Author:** [@Reginald](https://internals.rust-lang.org/u/Reginald)\
**Replies:** 6\
**Last updated:** [October 12, 2025, 7:09am UTC](https://internals.rust-lang.org/t/allow-panic-macro-to-take-static-strings-as-only-argument/23613 "2025-10-12T07:09:44Z")

</div>

I'm making an embedded library and I have multiple parts of my code which panic under similar conditions with the same message. Originally I just used string literals, but in an effort to clean up my code I wanted to use…

---

## [Diagnostic for #136932 width limit](https://internals.rust-lang.org/t/diagnostic-for-136932-width-limit/23589)

<div class="topic-metadata">

**Author:** [@matt-phylum](https://internals.rust-lang.org/u/matt-phylum)\
**Replies:** 2\
**Last updated:** [October 2, 2025, 11:36pm UTC](https://internals.rust-lang.org/t/diagnostic-for-136932-width-limit/23589 "2025-10-02T23:36:19Z")

</div>

\#136932 set an upper limit for the width of fields in a format string. It's a very high limit, but it's a lower limit than the compiler allows, and this creates a footgun where if the width is dynamic then your code may …

---

## [Preserve\_none-like behavior](https://internals.rust-lang.org/t/preserve-none-like-behavior/23580)

<div class="topic-metadata">

**Author:** [@Germ210](https://internals.rust-lang.org/u/Germ210)\
**Replies:** 0\
**Last updated:** [September 29, 2025, 10:49pm UTC](https://internals.rust-lang.org/t/preserve-none-like-behavior/23580 "2025-09-29T22:49:09Z")

</div>

I'm working on a threaded interpreter, is there a way to get the efficiency of the preserve\_none calling convention in rust? I'm using become for tail calling, but is there anything that can have minimal callee saving, w…

---

## [Stabilize the -Z profile-sample-use and -Z debug-info-for-profiling flags](https://internals.rust-lang.org/t/stabilize-the-z-profile-sample-use-and-z-debug-info-for-profiling-flags/23559)

<div class="topic-metadata">

**Author:** [@leo3308](https://internals.rust-lang.org/u/leo3308)\
**Replies:** 0\
**Last updated:** [September 24, 2025, 5:35am UTC](https://internals.rust-lang.org/t/stabilize-the-z-profile-sample-use-and-z-debug-info-for-profiling-flags/23559 "2025-09-24T05:35:25Z")

</div>

These flags have existed in the compiler for quite a long time, but they remain unstable. Are there any plans to move them toward stabilization? From what I understand: They can help reduce latency and CPU usage when …

---

## [Idea: Compile panick into Results?](https://internals.rust-lang.org/t/idea-compile-panick-into-results/23553)

<div class="topic-metadata">

**Author:** [@NobodyXu](https://internals.rust-lang.org/u/NobodyXu)\
**Replies:** 4\
**Last updated:** [September 21, 2025, 8:58am UTC](https://internals.rust-lang.org/t/idea-compile-panick-into-results/23553 "2025-09-21T08:58:42Z")

</div>

Instead of using libunwind/SEH for handling panick which would increase binary size, extra setup/deps at runtime, and hard to optimize/reason code for the compiler, what if rustc compiles panicks into Results in mir? Wi…

---

## [Unify \`ast/hir::Mutability\`](https://internals.rust-lang.org/t/unify-ast-hir-mutability/23551)

<div class="topic-metadata">

**Author:** [@ada4a](https://internals.rust-lang.org/u/ada4a)\
**Replies:** 2\
**Last updated:** [September 20, 2025, 7:37am UTC](https://internals.rust-lang.org/t/unify-ast-hir-mutability/23551 "2025-09-20T07:37:29Z")

</div>

Context: I wanted to create a helper function in clippy\_utils which would turn \<expr\> (a snippet) into &\<expr\> or &mut \<expr\>, depending on provided mutbl: Mutability. In the middle of writing it, I realized that it won'…

---

## [Suggest \_ instead of let \_ when unused\_must\_use is triggered](https://internals.rust-lang.org/t/suggest-instead-of-let-when-unused-must-use-is-triggered/23523)

<div class="topic-metadata">

**Author:** [@philomathic\_life](https://internals.rust-lang.org/u/philomathic_life)\
**Replies:** 6\
**Last updated:** [September 15, 2025, 3:32pm UTC](https://internals.rust-lang.org/t/suggest-instead-of-let-when-unused-must-use-is-triggered/23523 "2025-09-15T15:32:05Z")

</div>

This is purely a style recommendation, but it would be nice if the compiler suggested to assign a #\[must\_use\] value to \_ instead of let \_. Are there any drawbacks? I don't know the policy of compiler suggestions as it pe…

---

## [Compile const generics as arguments when optimized for size](https://internals.rust-lang.org/t/compile-const-generics-as-arguments-when-optimized-for-size/23496)

<div class="topic-metadata">

**Author:** [@pascaldekloe](https://internals.rust-lang.org/u/pascaldekloe)\
**Replies:** 2\
**Last updated:** [September 6, 2025, 5:55pm UTC](https://internals.rust-lang.org/t/compile-const-generics-as-arguments-when-optimized-for-size/23496 "2025-09-06T17:55:38Z")

</div>

The compiler could treat const generics as function arguments behind the scenes when in "z" optimization. E.g., fn f\<A: const u8\>(x: f32) could be read as fn f(x: f32, A: u8) instead. The idea is to have less logic dupli…

---

## [Can we use proper clang instead of llvm fork what rust uses?](https://internals.rust-lang.org/t/can-we-use-proper-clang-instead-of-llvm-fork-what-rust-uses/23489)

<div class="topic-metadata">

**Author:** [@new\_10](https://internals.rust-lang.org/u/new_10)\
**Replies:** 6\
**Last updated:** [September 5, 2025, 9:02am UTC](https://internals.rust-lang.org/t/can-we-use-proper-clang-instead-of-llvm-fork-what-rust-uses/23489 "2025-09-05T09:02:57Z")

</div>

Hi everyone, I was wondering can we use the official Clang instead of the LLVM fork that Rust uses? While looking into this, I compared the commit differences between the rust-llvm version and the official llvm-project …

---

## [Help: how to compile tier 3 target aarch64-unknown-nto-qnx700 under linux?](https://internals.rust-lang.org/t/help-how-to-compile-tier-3-target-aarch64-unknown-nto-qnx700-under-linux/23462)

<div class="topic-metadata">

**Author:** [@kipade](https://internals.rust-lang.org/u/kipade)\
**Replies:** 0\
**Last updated:** [August 27, 2025, 1:46am UTC](https://internals.rust-lang.org/t/help-how-to-compile-tier-3-target-aarch64-unknown-nto-qnx700-under-linux/23462 "2025-08-27T01:46:32Z")

</div>

I had first change my project from C to rust, but when I almost completed the project, I found my target platform aarch64-unknown-nto-qnx700 is tier 3 support for official Rust team. So, I think I will have to compile su…

---

## [Inferring generic parameter by intersecting trait impls](https://internals.rust-lang.org/t/inferring-generic-parameter-by-intersecting-trait-impls/23350)

<div class="topic-metadata">

**Author:** [@fwolter](https://internals.rust-lang.org/u/fwolter)\
**Replies:** 4\
**Last updated:** [August 10, 2025, 4:31am UTC](https://internals.rust-lang.org/t/inferring-generic-parameter-by-intersecting-trait-impls/23350 "2025-08-10T04:31:35Z")

</div>

Consider this minimal example: struct A; struct B; trait Ch1\<const N: u8\> {} trait Ch2\<const N: u8\> {} impl Ch1\<1\> for A {} impl Ch1\<2\> for A {} impl Ch2\<1\> for B {} impl Ch2\<3\> for B {} fn foo\<const N: u8\>(\_: impl …

---

## [Panic\_nounwind line numbers: is it technical restriction or design decision](https://internals.rust-lang.org/t/panic-nounwind-line-numbers-is-it-technical-restriction-or-design-decision/23344)

<div class="topic-metadata">

**Author:** [@davemilter](https://internals.rust-lang.org/u/davemilter)\
**Replies:** 2\
**Last updated:** [August 9, 2025, 3:56pm UTC](https://internals.rust-lang.org/t/panic-nounwind-line-numbers-is-it-technical-restriction-or-design-decision/23344 "2025-08-09T15:56:04Z")

</div>

If panic going to cross extern "C" boundaries then panic\_nounwind was called and process aborted, but why crash dumps not contain line number where panic was called, only line where extern "C" function was defined? I me…

---

## [Let crash = foo\[foo.len()\];](https://internals.rust-lang.org/t/let-crash-foo-foo-len/22910)

<div class="topic-metadata">

**Author:** [@Dwarsloeper](https://internals.rust-lang.org/u/Dwarsloeper)\
**Replies:** 20\
**Last updated:** [August 4, 2025, 10:36pm UTC](https://internals.rust-lang.org/t/let-crash-foo-foo-len/22910 "2025-08-04T22:36:00Z")

</div>

In Greg’s KubeCon keynote, he gave the above example :play\_button:. It makes me wonder why the compiler doesn’t catch this (and similarly) predictable out of bounds index in array and Vec. That not only catches such beg…

---

## [Very obstacle for Rust's metaprogramming](https://internals.rust-lang.org/t/very-obstacle-for-rusts-metaprogramming/23315)

<div class="topic-metadata">

**Author:** [@SarK0Y](https://internals.rust-lang.org/u/SarK0Y)\
**Replies:** 4\
**Last updated:** [August 4, 2025, 12:21am UTC](https://internals.rust-lang.org/t/very-obstacle-for-rusts-metaprogramming/23315 "2025-08-04T00:21:38Z")

</div>

Howdy, Dear Friends :slight\_smile: recently i been writing some tools for source’s management.. https://crates.io/crates/goto1717 https://crates.io/crates/rst\_lex crates.io: Rust Package Registry #\[cleanup(\_1st\_toke…

---

## [Stabilizing Linker Relaxation for RISC-V](https://internals.rust-lang.org/t/stabilizing-linker-relaxation-for-risc-v/23311)

<div class="topic-metadata">

**Author:** [@reynoldsbd](https://internals.rust-lang.org/u/reynoldsbd)\
**Replies:** 0\
**Last updated:** [August 2, 2025, 2:42pm UTC](https://internals.rust-lang.org/t/stabilizing-linker-relaxation-for-risc-v/23311 "2025-08-02T14:42:37Z")

</div>

Hi all! Looking to start a conversation about what it would take to stabilize the RISC-V “relax” target feature which was added a few years back. Linker relaxation is an important optimization for RISC-V (according to S…

---

## [Yet another stupid thought about specialization](https://internals.rust-lang.org/t/yet-another-stupid-thought-about-specialization/23271)

<div class="topic-metadata">

**Author:** [@DasLixou](https://internals.rust-lang.org/u/DasLixou)\
**Replies:** 3\
**Last updated:** [July 29, 2025, 7:56pm UTC](https://internals.rust-lang.org/t/yet-another-stupid-thought-about-specialization/23271 "2025-07-29T19:56:17Z")

</div>

Hehey yeah it's the most beloved topic: specialization. Up front, I want to say that I don't have deep knowledge about how the rust compiler really works, but it was too tempting to write this blog post, so yeah.. you a…

---

## [chunks\_exact(N) Item is &'a \[T\] and not &'a \[T: N\]](https://internals.rust-lang.org/t/chunks-exact-n-item-is-a-t-and-not-a-t-n/23279)

<div class="topic-metadata">

**Author:** [@john-parton](https://internals.rust-lang.org/u/john-parton)\
**Replies:** 7\
**Last updated:** [July 27, 2025, 11:07pm UTC](https://internals.rust-lang.org/t/chunks-exact-n-item-is-a-t-and-not-a-t-n/23279 "2025-07-27T23:07:57Z")

</div>

ChunksExact: ChunksExact in std::slice - Rust Some example (sound to my eye) code motivating this discussion: Rust Playground Calling .chunks\_exact(N) on an iterable results in chunks that are exactly N items long, but…

---

## [{{post#0}}](https://internals.rust-lang.org/t/post-0/23184)

<div class="topic-metadata">

**Author:** [@kornel](https://internals.rust-lang.org/u/kornel)\
**Replies:** 28\
**Last updated:** [July 24, 2025, 5:52pm UTC](https://internals.rust-lang.org/t/post-0/23184 "2025-07-24T17:52:16Z")

</div>

Rust doesn't have any explicit way to give closures a more recognizable name. Closures end up having non-descriptive names {{closure#0}} in paths and symbols, and noisy-looking types {closure@span}. When I'm profiling c…

---

## [Poor optimization of fallible construction of arrays from iterators](https://internals.rust-lang.org/t/poor-optimization-of-fallible-construction-of-arrays-from-iterators/23258)

<div class="topic-metadata">

**Author:** [@zackw](https://internals.rust-lang.org/u/zackw)\
**Replies:** 4\
**Last updated:** [July 22, 2025, 7:30pm UTC](https://internals.rust-lang.org/t/poor-optimization-of-fallible-construction-of-arrays-from-iterators/23258 "2025-07-22T19:30:35Z")

</div>

Poking around with variations on @newpavlov's "pathological bounds checking" example in the "pure annotations for stateless functions" thread, I found another case where the optimizer doesn't manage to do nearly as good …

---

## [Borrow checking without lifetimes and specialization soundness](https://internals.rust-lang.org/t/borrow-checking-without-lifetimes-and-specialization-soundness/23207)

<div class="topic-metadata">

**Author:** [@Serhii](https://internals.rust-lang.org/u/Serhii)\
**Replies:** 2\
**Last updated:** [July 11, 2025, 9:16am UTC](https://internals.rust-lang.org/t/borrow-checking-without-lifetimes-and-specialization-soundness/23207 "2025-07-11T09:16:46Z")

</div>

After reading a blog post borrow checking without lifetimes it made me wonder whether this could be a solution to the specialization unsoundness issue. For example in shipping specialization: a story of soundness the …

---

## [Can we skip borrow checking by caching MIRs and borrowck results?](https://internals.rust-lang.org/t/can-we-skip-borrow-checking-by-caching-mirs-and-borrowck-results/23189)

<div class="topic-metadata">

**Author:** [@cordx56](https://internals.rust-lang.org/u/cordx56)\
**Replies:** 4\
**Last updated:** [July 11, 2025, 3:21am UTC](https://internals.rust-lang.org/t/can-we-skip-borrow-checking-by-caching-mirs-and-borrowck-results/23189 "2025-07-11T03:21:37Z")

</div>

We are experimenting with caching MIRs and borrowck results to skip borrow checking for already checked code. Is this possible? The mir\_borrowck function takes a TyCtxt as an argument, so we are not confident.

[Previous page](https://internals.rust-lang.org/c/compiler/20.md)

[Next page](https://internals.rust-lang.org/c/compiler/20.md?page=2)
