Add fallible allocation methods

[nbdd0121]

These are all fallible alternatives to all currently used methods that may perform infallible allocation.

assume_fallible is a semantically marker function to denote that we have proved that the closure passed to it will not perform infallible allocation.

After this change, the code can be verified to not perform any infallible allocation using the tool I have just completed: https://github.com/nbdd0121/klint
(you can try the tool on Linux repo by rustup run nightly make CLIPPY_DRIVER=klint CLIPPY=1, beware it's quite noisy when compiling libmacros!)

[ksquirrel]

Review of 6b0a5e92b5e4:

• ✔️ Commit 6b0a5e9: Looks fine!

[bjorn3]

After this change, the code can be verified to not perform any infallible allocation using the tool I have just completed: https://github.com/nbdd0121/klint

💖 That tool looks really nice!

[TheSven73]

Nice!

Now that allegedly there's no more need for fallible allocations, is it perhaps possible to disable them, i.e. make the build fail if someone tries to use them? And would that be preferable to using a linter for that purpose?

[nbdd0121]

Nice!

Now that allegedly there's no more need for fallible allocations, is it perhaps possible to disable them, i.e. make the build fail if someone tries to use them? And would that be preferable to using a linter for that purpose?

Ideally we could just disable the infallible methods, but we couldn't do it yet as otherwise we have to re-implement most of alloc crate ourselves :(

So I thought it might be a good compromise to use a linter as a temporary solution until we're ready to disable them completely.

P.S. I always find infallible and fallible to be kind of confusing, since infallible allocation means the allocation is not allowed to fail (but allowed to panic!) while fallible means the allocation is allowed to fail (and thus should not panic!).

[ojeda]

This is very nice -- Clippy-like kernel lints for the Rust side is something that we definitely want to have. And integrating with the compiler is a better approach than e.g. the regexp one used by some of the tools for C (nothing against that -- I assume they went that way because writing compiler plugins for GCC was not easy many years ago).

I was thinking we would have such a tool as a "Clippy fork", i.e. adding our checks there, but I guess an independent tool also makes sense -- not sure about pros/cons.

On the allocations: I am not sure about putting the changes in, since we have to remove the allocations soon anyway (I will be focusing on that this week).

[nbdd0121]

On the allocations: I am not sure about putting the changes in, since we have to remove the allocations soon anyway (I will be focusing on that this week).

Oh great! Do you plan on using the no_global_oom_handling config and use extension traits or an liballoc fork?

I think it's best to avoid forking liballoc as it depends on a ton of nightly features that we don't really want to depend on. Some examples include lang items, fundamental, coerce unsized, custom receiver trait, unsized local, etc etc.

[ojeda]

The three times I re-started that (and then got sidetracked), I went the forking way (no_global_oom_handling did not exist anyway). The nightly features are indeed a major problem, but I think it is a nice exercise for both Rust and the kernel; plus it does give us a lot of freedom.

But yeah, we will see how it looks. If it is too bad, we can definitely go with no_global_oom_handling + ext traits. I wanted to give the forking way at least a serious try (including PR etc.), because I wanted to have a discussion on it. Given the next informal meeting is this Saturday, I think it is a nice time for me to focus on it.

[nbdd0121]

Close as we have #402 now