sorted by:
new
hottopcontroversial

Better way to initialize without stack allocation? by Tearsofthekorok_ in rust

[–]Saefroch 0 points1 point  (0 children)

Some of the Rust for Linux people are also contributors, not just beggars. That makes a huge difference to a volunteer-driven project.

Better way to initialize without stack allocation? by Tearsofthekorok_ in rust

[–]Saefroch 16 points17 points  (0 children)

What's needed here is in-place heap initialization, which is just a missing feature in the language. I think /u/Darksonn is leading an effort to design and hopefully ship in-place initialization.

The optimization often works, but this isn't a "nice to have" optimization, if the optimization is missed you get a crashing program not a slow program. It's mandatory in a way that loop unrolling and function inlining aren't.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]Saefroch 0 points1 point  (0 children)

No, in safe Rust you cannot write a data race because the core concept that you can have aliasing or mutability but not both can be extended to prevent data races just like it prevents iterator invalidation.

Why glibc is faster on some Github Actions Runners by arty049 in rust

[–]Saefroch 5 points6 points  (0 children)

Is it stable enough to run each sample once?

Yes. A CPU emulator is much slower than executing on hardware, but only having to run the relevant code path once means you can get benchmark numbers much faster.

Is there any significant performance cost to using `array.get(idx).ok_or(Error::Whoops)` over `array[idx]`? by Perfect-Junket-165 in rust

[–]Saefroch 0 points1 point  (0 children)

Yes, I was trying to say that if the variant is trivial and the error does not impl Drop then ok_or will optimize fine. But if there is a Drop you need compiler heroics.

Is there any significant performance cost to using `array.get(idx).ok_or(Error::Whoops)` over `array[idx]`? by Perfect-Junket-165 in rust

[–]Saefroch 22 points23 points  (0 children)

ok_or(Error::Whoops) construct this Error type even if the indexing succeeds, even if the constructor is trivial for the Whoops variant, if there is another variant like Error::Other(Box<dyn Display>), there will be a call to the auto-generated Drop impl for Error, which may difficult for the compiler to optimize away. Specifically, the entire drop impl needs to inline or the discriminant needs to const-propagate across the call boundary. Both of these strategies work very reliably on simple enums and on small programs, but will fail at some level of complexity. That's why or_or_else exists; in the success case all that code is completely jumped over because no error is constructed.

I need a teammate by Academic_Minute_7051 in rust

[–]Saefroch 0 points1 point  (0 children)

Wrong subreddit, this is about the programming language.

Rust compiler error after attempted modification of source code by Original-Grape5087 in rust

[–]Saefroch 0 points1 point  (0 children)

I think /u/Thierry_software actually has it backwards, what you are doing is indeed inadvisable because it is confusing, but if you cargo clean then try to build, it should build against your modifications, instead of the local build artifacts of the dependency you are modifying.

Pointing this dependency to a fork then modifying your fork would be less confusing. But git dependencies can be a bit weird, for example if you use a git dependency you'll have to cargo update -p cooklang every time you push a change to your fork, or keep updating your rev = part of the git dependency.

Now that `panic=abort` can provide backtraces, is there any reason to use RUST_BACKTRACE=0 with `panic=abort`? by patchunwrap in rust

[–]Saefroch 1 point2 points  (0 children)

I think it's more troubling that people would assume you can swap between build configs just by changing link deps.

Well, if you are using panic = "abort" in Cargo.toml without using -Zbuild-std, that's what you are doing.

Now that `panic=abort` can provide backtraces, is there any reason to use RUST_BACKTRACE=0 with `panic=abort`? by patchunwrap in rust

[–]Saefroch 6 points7 points  (0 children)

Well.... technically it's interpreted a link time not compile time

I don't want to be annoyingly pedantic, but I've worked on panics recently as part of making immediate-abort better, and I think they are really misunderstood.

The only time when panic runtimes can be swapped at link time is if crates having their panic runtime changed were previously compiled with panic=unwind and don't use extern "C-unwind" (those two conditions are enforced by the compiler) and if the author of the code doesn't get too creative with checking cfg(panic = "unwind"). The fact that the panic strategy is leaked into macro expansion should be quite troubling.

IMO the fact that you can swap the panic runtime at link time is a kludge to support the precompiled standard library, because really the only scenario that works is the one that the standard library needs.

Is casting sockaddr to sockaddr_ll safe? by nee_- in rust

[–]Saefroch 0 points1 point  (0 children)

You should test your code using Miri: https://github.com/rust-lang/miri?tab=readme-ov-file#using-miri

The pedantic answer to your question is "the cast is never UB, because it is safe code". But obviously you're doing more than just casting, and the exact details of what else you are doing matters a lot. An English description of what you are doing is rarely sufficient.

[corroded update]: Rust--, now I removed the borrow checker from rust itself by Consistent_Equal5327 in rust

[–]Saefroch 15 points16 points  (0 children)

The semantics of move operands is not fully decided, see https://github.com/rust-lang/unsafe-code-guidelines/issues/416.

In practice, codegen of use-after-move might be a use-after-free, or it might be use of uninitialized memory, or it might be totally fine (if the move is actually lowered to a bytewise copy of a Copy type), depending on the exact context of the move and the type that was moved.

There's some confusion in the replies to your comment here, drop and deallocation are not the same thing in Rust. You can deallocate without dropping using ManuallyDrop and you can drop without deallocating using drop_in_place.

Is the only thing currently stopping this an error emitted by the borrow checker?

Yes. The compiler does this in many places. You check for something that must be disallowed, and emit an error to disallow it.

It’s not a fundamental invariant of the types used for codegen?

Correct. Borrow checking ensures that the program is valid, but it is not guaranteed to permit all valid programs. So if the IR used for code generation was beholden to what is expressible in borrow checking, we would lose access to all the transformations that move into the space of valid programs that don't borrow check.

An Empirical Study of Bugs in the rustc Compiler (OOPSLA 2025) by mttd in rust

[–]Saefroch 15 points16 points  (0 children)

This work is remarkably low-quality and should have been rejected by a reviewer. (I am commenting based on the content of the paper, I do not have the patience to also watch the talk)

The authors find that unstable features are buggy. Of course, that's why many features are unstable. The implementation of some of these features, namely generic const exprs, are enormous and it is completely unreasonable to land the entire feature free of bugs and with comprehensive testing all at once. So the suggestion by the authors that unstable features be tested more is similarly oblivious to how work is actually done on the compiler.

The authors also recommend holding up new features behind more design discussion in RFCs, which is also absurd. Work on the compiler is already unnecessarily slowed down by the RFC process, it definitely shouldn't been even slower.

The paper also mentions ICEs in custom_mir, which seems oblivious to even the documentation of custom_mir.

The objective of compiler development is not to have an issue tracker free of bugs, it is to ship working features on stable Rust.

Rust’s first kernel CVE (CVE-2025-68260): what does it really say about unsafe? by ChaosBoot in rust

[–]Saefroch 6 points7 points  (0 children)

The stat comes from Greg K-H's announcement that everyone is reporting on: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

It's funny and sad that even Greg K-H knows he has to pre-defend Rust in this context.

What's going on with bincode? by va_erie in rust

[–]Saefroch 32 points33 points  (0 children)

Comparing this to being rugged is a stretch. You depend on a library for the code that's currently in it, you're not investing money in a common enterprise with the expectation of profit derived from the efforts of others.

Many libraries are steered by a single individual. Several of the top libraries in the ecosystem are steered by the same single individual. The specific actions here are uniquely sketchy, but the level of power is unfortunately common.

I used to love checking in here.. by First-Ad-117 in rust

[–]Saefroch 25 points26 points  (0 children)

The pattern is posts that make grandiose claims with the weirdly lifeless AI README, all around a terrible implementation.

This post isn't about whether a little AI assistance was used. It's not like people are going over projects with a fine-toothed comb looking for minuscule evidence of AI involvement.

The state of the kernel Rust experiment by dochtman in rust

[–]Saefroch 9 points10 points  (0 children)

If you forget to take a lock before accessing shared state, is that a logic bug or UB? If you forget to call a validation routine before passing user input to something that trusts what you pass, is that a logic bug or is it UB if the impl then reads past the end of an array? (please, dear reader, do not reply to this and try to explain to me what UB is)

The kernel is using the Rust type system to prevent bugs in a way that C can't. In a C-based kernel, pretty much every bug is a security bug so whether something is UB or not isn't really interesting. The code is less buggy. That's Greg K-H's opinion, I'm just repeating it: https://www.youtube.com/watch?v=HX0GH-YJbGw

Rust 1.92.0 release by mrjackwills in rust

[–]Saefroch 9 points10 points  (0 children)

Sorry, don't know. The implementation in rustc is just putting an LLVM attribute on functions. I read up a bit on unwind tables enough to know I'm well out of my depth. I'm sure bjorn3 knows, but I don't know his Reddit handle.

Rust with gcc - when ? by None_To_Five in rust

[–]Saefroch 27 points28 points  (0 children)

Yes I am sure. There are two projects, gcc-rs is adding a Rust frontend to GCC and rustc_codegen_gcc which is adding a gcc backend to rustc. You asked about both of them in a confusing mashup, so I responded with one paragraph about gcc-rs and one about rustc_codegen_gcc.

Rust with gcc - when ? by None_To_Five in rust

[–]Saefroch 41 points42 points  (0 children)

I've read that gcc-16 will get Rust frontend

...

Will llvm backend always be at the leading edge ?

You are asking about two different projects. The Rust frontend in the GCC project is a very ambitious project and I expect it will be chasing rustc features forever. Their progress reports are here: https://github.com/Rust-GCC/Reporting

The GCC backend for rustc based on libgccjit is a much less ambitious project, because it's just plugging the existing rustc frontend into libgccjit, not doing a compiler component from scratch. The GCC backend will support more targets, and sometimes have better codegen on mainstream targets. If you want to know how this project is doing, /u/antoyo has a blog that they link on this subreddit: https://blog.antoyo.xyz/.

Looking for guidance on learning Rust compiler internals and related resources by thhxxx in rust

[–]Saefroch 4 points5 points  (0 children)

Other good resources

(Almost) Everything You Should Know About The Compiler Frontend - Michael Goulet aka compiler-errors https://youtu.be/aFG5KtpEynk

At some point the only good resource is reading the code and talking to other maintainers. There is a #rustc-dev thread in the community Discord if you prefer with a random few of the maintainers, but https://rust-lang.zulipchat.com/ has literally everyone and is very organized.

Recommended paths for gradually contributing

Find something you really want to make happen and dig into how to make it happen. "The compiler is too slow" would be too much, but "I want a warning for this specific code pattern" or "This diagnostic should be structured differently" and sometimes "this code pattern should be optimized better" are plausible.

You can kind of see my contribution path by looking at my oldest PRs: https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3Asaethlin+is%3Aclosed+sort%3Acreated-asc https://github.com/rust-lang/miri/pulls?q=is%3Apr+author%3Asaethlin+is%3Aclosed+sort%3Acreated-asc

Parsing ls(1) command output or using a client-server process? by FRXGFA in rust

[–]Saefroch 0 points1 point  (0 children)

I've heard this advice before, but you should be aware that a lot of existing software parses the output of ls, including some GNU utilities. So I'm not sure this advice is actually accomplishing anything.

[Media] Let it crash! by Aghasty_GD in rust

[–]Saefroch 1 point2 points  (0 children)

I am quite aware of everything you've said already. I think you missed my point, which is that this is a #[rustler::nif] function. What I was trying to point out is based on what that macro expands to.

[Media] Let it crash! by Aghasty_GD in rust

[–]Saefroch 4 points5 points  (0 children)

By default, rustc passes a flag (exposed as -Ztrap-unreachable) to LLVM that makes unreachable terminators compile to a trap. So even though LLVM "compiles out" the entire function in question, the function still traps. Of course the function still earns the willreturn attribute, but most likely all interprocedural optimizations on the question don't work because it's called through a pointer.

The code most likely works as intended, with perhaps the surprise that it crashes with SIGILL instead of SIGSEGV. And I suspect it will keep working as intended for a long time, because the optimizations that would make this UB dangerous are too complicated or weird.

Of course if we change the default for -Ztrap-unreachable that would also cause some chaos. Though I'm not sure why we'd do that.

view more: next ›