[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=PakH-25ZAhC-TKNq7ti76cKt-coS4UahUjsGxNVWRAQ@mail.gmail.com>
Date: Wed, 14 Apr 2021 21:34:35 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
rust-for-linux@...r.kernel.org,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Geoffrey Thomas <geofft@...reload.com>,
Finn Behrens <me@...enk.de>,
Adam Bratschi-Kaye <ark.email@...il.com>,
Wedson Almeida Filho <wedsonaf@...gle.com>
Subject: Re: [PATCH 05/13] Rust: Compiler builtins crate
On Wed, Apr 14, 2021 at 9:19 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Not being a Rust person, I can only guess based on random pattern
> matching, but this _looks_ like these "panicking intrinsics" panic at
> run-time (by calling BUG()).
Your pattern matching works well :)
> Is there some way these things could cause built-time link errors
> instead, so that if somebody uses 128-bit shifts, or floating point
> ops in the rust code, they show up as build failures, not as run-time
> ones?
Yes, we should definitely make this a compile-time error if possible!
This was the easy way out for the moment.
In general, there are some things that are currently unneeded from the
Rust standard library. When we get to remove those, many of those
intrinsics should go away, and then we can leave it as a link error.
Cheers,
Miguel
Powered by blists - more mailing lists