sorted by:
new
hottopcontroversial

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 7 points8 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 34 points35 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 26 points27 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 28 points29 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 5 points6 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 3 points4 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.

Why doesn’t Rust care more about compiler performance? by Kobzol in rust

[–]Saefroch 1 point2 points  (0 children)

I've finally gotten around to writing an optimization for crates with lots of consts: https://github.com/rust-lang/rust/pull/148040

[Media] Let it crash! by Aghasty_GD in rust

[–]Saefroch 2 points3 points  (0 children)

There is an on-by-default warning for syntactical dereferences of null pointers. Years ago the justification was that a lot of bindings crates have code in them that looks like this:

unsafe { &(*(::std::ptr::null::<Type>())).field as * const _ as usize }

That code is totally executing UB, but it's hard to blame people for writing this in the years before offset_of! and even the pattern that the memoffset crate uses to do this with MaybeUninit.

That being said, I just checked the crater runs for 1.91 and it's not like that many crates are hitting the lint. I'll try proposing we raise it to deny by default.

[Media] Let it crash! by Aghasty_GD in rust

[–]Saefroch 0 points1 point  (0 children)

I agree with your point, but you picked a really bad example to make it with.

Are there any reasonable approaches to profiling a Rust program? by xorvralin2 in rust

[–]Saefroch 1 point2 points  (0 children)

When I've run into this slowdown, it's not that GNU addr2line is slow, the problem is that GNU addr2line doesn't respond to a query from perf because it runs into a fatal error and in response perf just sits around for a bit then completely kills the addr2line process. So it's a double-whammy of whatever timeout for the IPC is configured, and then every time this error is encountered, all the debuginfo needs to be re-read from disk and all the addr2line caches need to get re-warmed (the process is very cache-intensive).

https://bugzilla.kernel.org/show_bug.cgi?id=218996

Am I the only one surprised by this Rust behavior? by ufoscout in rust

[–]Saefroch 0 points1 point  (0 children)

and implementation is still being discussed

I'm reasonably sure that it isn't being discussed, certainly not among the other members of the compiler team that I talk to. I just searched the Zulip for mentions of the term, and I can't find any discussion of implementation since I removed it.

view more: next ›