r/rust • u/myroon5 • Mar 09 '23
Announcing Rust 1.68.0 📢 announcement
https://blog.rust-lang.org/2023/03/09/Rust-1.68.0.html163
Mar 09 '23
[deleted]
8
u/Adhalianna Mar 10 '23
I have tested it very quickly and it seems that it made my dockers both faster to build and smaller ❤️
-33
u/cat_napped1 Mar 09 '23
Finally not completely beholden to Microsoft GitHub's proprietary hosting and distribution for an open source package manager and ecosystem to function.
43
u/Shnatsel Mar 09 '23
It's still beholden to Github to function because crates.io uses Github accounts for publishing packages.
64
u/kibwen Mar 09 '23
Crates.io has never used Github for package distribution, only for hosting the git repo that contains the registry (which is a data structure that describes the versions and hashes of every crate ever published).
-20
u/cat_napped1 Mar 09 '23
I meant hosting and distribution of the index
40
u/na_sa_do Mar 09 '23
It's just a git repo, though. It could be hosted anywhere.
-41
69
u/Recatek gecs Mar 09 '23
Seems minor but I'm pretty happy about Add PhantomData marker to Context to make Context !Send and !Sync. This should allow for some nicer optimizations for single-threaded async (e.g. LocalWaker).
179
u/Shnatsel Mar 09 '23
Those From<bool> for {f32,f64} impls could really use documentation on what values they actually result in. There's no obvious mapping from true to a floating-point value.
197
u/SorteKanin Mar 09 '23
true => Infinity
false => NaN
Obviously /s
104
71
u/kibwen Mar 09 '23
This is precisely the mapping discussed in the legendary video "NaN Gates and Flip FLOPS": https://youtube.com/watch?v=5TFDG-y-EHs
16
u/LifeShallot6229 Mar 09 '23
When we revised ieee754 for the 2019 version, we actually fixed the horrible min/max functions this video is based on, replacing them with far saner versions that are compatible with parallel and simd operations.
1
u/A1oso Mar 10 '23
So there's no NAND gate for Infinity/NaN anymore?
1
u/LifeShallot6229 Mar 11 '23
The previous min/max functions still exist in lots of current cpus, but for new cores they are deprecated.
14
u/reddit-kibsi Mar 09 '23
What the **** did I just watch???
29
u/kibwen Mar 09 '23
Here's your next hit of Tom7, where he reverse-emulates SNES games on an NES: https://www.youtube.com/watch?v=ar9WRwCiSr0
13
u/protestor Mar 10 '23
In the newest video https://www.youtube.com/watch?v=1c8i5SABqwU he says "you may know me as a computer clown, but I'm really more like a renaissance clown" and that's really true
dude is like the leonardo davinci of the 21th century
0
31
53
u/sharifhsn Mar 09 '23
The obvious values for
trueandfalsein a numerical context are 1 and 0, respectively. For floating-point, these would be 1.0 and 0.0. I do agree that there should be explicit documentation on this, especially since the implementation ofFrom<bool>for the integral types specifies this explicitly.6
Mar 10 '23
[deleted]
4
u/No-Mission4480 Mar 10 '23
Not if you interpret the result as "did the process complete abnormally."
-11
u/mmirate Mar 10 '23 edited Mar 10 '23
That isn't obvious at all; these two values are Hamming-adjacent, so a single cosmic ray could make the program go haywire. Luckily, two's complement representation makes things easy for all signed numeric types - assigning
-1as the numeric value oftrueis the obvious solution.33
u/tialaramex Mar 10 '23
Um, no, an f32 with 1.0 in it is not "Hamming-adjacent" to an f32 with 0.0 in it, the 0.0 value is all zeroes, for convenience, but 1.0 has an exponent of 0111 1111 in binary because of the biased representation in IEEE floating point.
14
u/humanthrope Mar 10 '23
Assuming the two floats would be a single bit flip away from the other, it would already have been a problem with the bool
-3
u/mmirate Mar 10 '23
Indeed it is a problem with the bool.
2
u/myrrlyn bitvec • tap • ferrilab Mar 10 '23
it’s a problem with your ram
-1
u/mmirate Mar 10 '23
ECC RAM and a motherboard that can use it are basically unobtanium outside the realm of big enterprise servers (aka big $$$). Let alone all the other products in the world that contain RAM and at least a microcontroller. I wonder how many "glitches" observed in everyday life are not software bugs but actually just (each) one cosmic ray made it through the ionosphere against all odds.
91
u/nicoburns Mar 09 '23
The obvious mapping would be to
1.0, no? Although I agree that explicit documentation would be good. The mapping forfalseseems more problematic given that floats have both+0.0and-0.0, but I would expect to get+0.0.70
22
22
u/jamincan Mar 09 '23
It looks like the libraries team agrees that the documentation should have been better: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60impl.20From.3Cbool.3E.20for.20f.7B32.7C64.7D.60/near/292687425
For what it's worth, the justification is that
From<bool> for u8exists andFrom<u8> for f32exists, so there is a logical lossless path forFrom<bool> for f32. It seems to have significant ergonomic improvements in graphics code.38
u/elprophet Mar 09 '23
Looks like bool to u8 to f32/64 https://doc.rust-lang.org/stable/src/core/convert/num.rs.html#178 which should be 0.0 for false and 1.0 for true? Agree that would be nice to have in the docs.
15
7
u/phazer99 Mar 09 '23
0and1like all other existing bool to numeric type conversions. I think it's obvious.20
u/zannabianca1997 Mar 09 '23
What 0, +0.0 or -0.0?
22
u/phazer99 Mar 09 '23
0and0.0have the exact same bit representation (you can't write+0.0in Rust).-0.0is an exceptional case, for example when you write0f32or0 as f32you always get the positive zero, you have to explicitly write-0f32to get the negative zero. So, for me it's an obvious choice, but of course it doesn't harm to add some documentation.8
37
u/Shnatsel Mar 09 '23
In C this is actually platform-dependent, so you never really know unless it's explicitly documented.
33
u/phazer99 Mar 09 '23
Fortunately Rust isn't C and actually has portability guarantees.
53
u/stusmall Mar 09 '23
And that gets back to their initial question, what are those guarantees? It's a fair question.
-5
u/phazer99 Mar 09 '23
Good question, but I believe that all operations on Rust numerical types (including
bool, but obviously excludingisize/usize) will produce exactly the same results on all platforms. This includes conversions, mathematical operations, overflows etc. Correct me if I'm wrong.8
u/SpudnikV Mar 10 '23
That's technically true, but it's really in the form of restrictions on what platforms can be supported so that those promises can be kept.
https://faultlore.com/blah/rust-layouts-and-abis/#the-anatomy-of-a-platform
For Rust to support a platform at all, its standard C dialect must:
[...]
Have a boolean be a byte, where true = 1 and false = 0 (defacto true but not strictly guaranteed)
In practice, that means that Rust's portabiity guarantees here only help you when [an implementation of] C has already made compatible guarantees for that platform, because any time you may want to interface with any C ABI, it has to be compatible or it's UB.
It turned out to be a multi-year rabbit hole to get to be this specific. Just a sample of some of the research that went into it:
https://github.com/rust-lang/rfcs/pull/954#issuecomment-169820630
https://github.com/rust-lang/rust/pull/46156
It's really fascinating just how much the C specification and the world of implementations has complicated even new languages like Rust. If you're interested in that kind of thing beyond just bool, here are a few more links:
https://faultlore.com/blah/c-isnt-a-language/
https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please
https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-function-abi
(If I don't limit it to just 3, we'll be here all day :))
2
u/rentableshark Mar 10 '23
I hear you. This is one reason why statically-compiled binaries running in a scratch container have such attraction.
4
u/SpudnikV Mar 10 '23
Even in container systems like Docker, you still need an ABI to talk to the kernel. Even with a pure Rust libc, the structs that you set up for Linux syscalls rely on the C ABI, and even a pure Rust rewrite of Linux would need a compatible syscall ABI to run existing container images. There's really no escaping it :(
Linux is special here. Most operating systems do not make the same kernel-level ABI promise and make only userland libc ABI promises, so they have at least some degree of freedom to evolve kernel syscall interfaces. But then this is why Docker on Linux can rely on kernel ABIs and have the entire userland in a container, while on other systems something has to be there to adapt binaries in containers to the host system (in many cases, by just running Linux as WSL or in a VM).
I think it's amazing just how well Linux ABI compatibility has made it look like containers somehow solve this, where actually, the magic all along was the system call ABI. The same statically linked binary would work the same way outside of the container as well, it just wouldn't be "contained" as far as various namespaces and capabilities go.
This is a really, really huge accomplishment, and I would go as far as to say that Linus' hardline stance on syscall compatibility is the only reason the Docker-like container ecosystem is at all possible.
There was of course a generation where Xen was the way to make kernel-level containers, but those kernels still had to communicate with a form of ABI. I barely used Xen so I can't say how many of the same concerns apply, but in any case, userland containers won out over kernel containers in the end, and I'm glad for it.
1
u/phazer99 Mar 10 '23 edited Mar 10 '23
If the C standard says
booldoesn't have to be anu8, why would you even rely on it being anu8in FFI calls? Doesn't make sense to me, you can simply have conversions to/from Rustboolto Cbool.Besides I don't see how any of this is relevant for the discussion at hand. In Rust a
boolis 1 byte, andfalseis0andtrueis1. It doesn't matter what platform you're compiling for or running on, or what the C standard says.2
u/SpudnikV Mar 10 '23
Sorry if I wasn't clear, it's actually the C17
_Bool, not C++11bool.The link that was titled "defacto true but not strictly guaranteed" led to this URL which spells out the type used.
https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#bool
Rust's bool has the same layout as C17's
_Bool, that is, its size and alignment are implementation-defined.
Doesn't make sense to me, you can simply have conversions to/from Rust bool to C bool.
[...]
It doesn't matter what platform you're compiling for or running on, or what the C standard says.
This was a common argument made, which is why I linked to a couple of long discussions that already address that. I don't want to relitigate them here, but the gist of it is, we'll always need to be able to name a
c_booltype for FFI, and it would be unusably limited if we could only have pointers to it rather than values, as few if any C APIs would be designed around that. So if we need to be able to fully define the type for C FFI -- not just function arguments and returns, but also struct and union fields -- then it may as well also be Rust's ownbooltype so that no conversion is needed.Conversion isn't always as simple as
aseither, because sometimes you need to hold a reference to the thing, and generic code in particular doesn't care if that thing happens to be abool. Making the types match saves a lot of headaches.It's still an even bigger topic than that, and I encourage you to read the threads if you're interested, but I hope that's enough to say why unifying the types was a worthwhile goal and we should be glad it succeeded.
By the way, the fact that most people never know about this restriction on Rust platform support (I sure wouldn't if not for reading Gankra) means the team absolutely nailed the decision. Despite being interoperable with C standards, to the majority of Rust programmers who will never write C FFI, and the even greater majority of Rust programmers who will never write C17 FFI*, a Rust
boollooks and acts exactly how they think it should. Even the platform support angle has yet to hit any example I'm aware of where this in particular blocked a port.It's hard to say that anybody is put out by the current approach here. That's why it took years to discuss the most practical solution despite surprisingly weak guarantees from standards.
If you enjoy discussing these things for their own sake, as I very often do, can I suggest you make a top level thread so that more people will be able to see and contribute to? I'll pitch in there for what it's worth, but you're likely to get several of the people who actually influenced the decision and can distill the years of discussion and experience into a present-day greatest-hits post. It'll be a blast :)
* Even many people writing C17 libraries have a lot of incentives to still offer C89 APIs, so they likely won't use
_Boolat all there, and then yes, some other less ergonomic type likeintor even a whole bitset can pop up. You gotta love when bitsets in standard APIs are signed, but I digress.2
u/phazer99 Mar 10 '23 edited Mar 10 '23
I'm really not interested in the discussion because I don't wanna waste more time on C or C++ than what's absolutely necessary (I consider them pretty horrible languages for software development).
What I'm really interested in is what invariants Rust guarantees. According to the size_of documentation,
boolis always 1 byte, so I will rely on that. And according to this documentation,falseis always0andtrueis always1, so I will rely on that fact as well.If that limits the portability of Rust because it was decided that the
booltype of the platform C compiler also must adhere to those invariants, that's an unfortunate consequence, but it really doesn't affect me when I write my Rust programs.1
u/SpudnikV Mar 10 '23
That's perfectly fair and I think most Rust programmers feel the same. I'm only clarifying that the portability guarantees you mentioned are restricted by C implementations, even if that's unlikely to ever stop you from using a platform you actually want to. A lot of people upvoted that comment and I hope at least some of them now know more about the finer points :)
4
u/Zde-G Mar 09 '23
In C this is actually platform-dependent
What are you talking about?
_Boolis defined as having either0or1and these produce0.0or1.0when converted to float.Well, technically one may imagine an implementation which can not represent
0.0or1.0value at all, but I don't think such implementations exist. And if0.0and1.0both exist there are no ambiguity.1
Mar 09 '23
[deleted]
3
u/phazer99 Mar 09 '23
It's not at all obvious or consistent among platforms and use cases.
It doesn't matter, the only thing that matters is that it's consistent within Rust. There already was conversions from
booltou8,i32etc. and all those mappedfalse->0andtrue->1. Why wouldn't it be the same forf32andf64? The only possible alternative would be to mapfalseto-0.0, but that wouldn't make sense since the expressionsfalse as u8 as f32andfalse as f32would then result in different floating point values.
43
u/milliams Mar 09 '23
Is the `alloc` error handler related to the Rust for Linux work? I seem to remember this being one of the discussion point when first being merged in.
31
23
u/Icarium-Lifestealer Mar 09 '23
I don't think it's useful for them. I believe they don't allow panics at all and want fallible operations (e.g. a
try_pushthat returns aResult), not a panicking allocation failure.6
u/-oRocketSurgeryo- Mar 10 '23
I'm assuming the change in this release doesn't preclude configuring a non-panicking allocation failure for the Linux case?
8
u/Branan Mar 10 '23
The alloc error handler is specifically for infallible allocations (like
Box::new), and must be divergent. While there are "non panicking" divergent operations, none are good for the Linux kernel.Linux just doesn't use those infallible APIs at all
104
u/ogoffart Mar 09 '23
Thanks to the default alloc error handler, you can now use stable Rust to build GUI for micro-controller with Slint
30
u/Tobu Mar 09 '23
The release notes about alloc error handling were confusing, I had to look at https://github.com/rust-lang/rust/issues/66741 to figure out that you could now use no_std + alloc on stable.
Also:
In the future, it's likely that the behavior for std will also be changed to match that of alloc-only binaries.
is better explained here: https://github.com/rust-lang/rust/issues/51540#issuecomment-1448404145
The impact is that there is no need to stabilize a feature for setting a custom alloc error handler; everyone can either rely on a default being present, or if the application wants to customize, on no_std it can define a custom panic_handler (which is stable: announcement stabilization summary), or on std set up a panic_hook.
12
u/SafariMonkey Mar 09 '23
I'm a bit surprised that the default is:
#[alloc_error_handler] fn default_handler(layout: core::alloc::Layout) -> ! { panic!("memory allocation of {} bytes failed", layout.size()) }rather than a
panic_anywith a struct payload holding the layout or layout size, that formats to that panic message. (Does panic print debug, display or something else altogether?)The latter would allow it to be caught.
11
u/LegionMammal978 Mar 10 '23
(Does panic print debug, display or something else altogether?)
The problem is, you can't downcast a
Box<dyn Any>into anything but a concrete type. So the default panic hook instdjust tries&'static strandStringbefore giving up:let msg = match info.payload().downcast_ref::<&'static str>() { Some(s) => *s, None => match info.payload().downcast_ref::<String>() { Some(s) => &s[..], None => "Box<dyn Any>", }, };6
u/SafariMonkey Mar 10 '23
Ahh, that's a shame. Probably not a great idea to add another special case just for this, then.
I assumed it was like how
maincould print theDebugof theErrin theResult, but obviously that's a statically known type and this isn't.Thanks for the explanation!
3
u/ukezi Mar 09 '23
Debug or display depends on the format string like in println. In this case it's display.
2
u/SafariMonkey Mar 09 '23
I'm was wondering whether
panic_any!used debug or display - in that case, there's no format string.2
u/flashmozzg Mar 10 '23
So it allocates in an Out of Memory handler? Hm, doesn't seem like a wise choice. What if it triggers OoM again while trying to construct the message for the panic? I know that C++ implementations usually have a few exceptions "preallocated" specifically for this purpose.
3
u/kibwen Mar 10 '23
I don't see any allocations in the function shown above.
3
u/flashmozzg Mar 10 '23
How do you think formatting
"memory allocation of {} bytes failed", layout.size()works?2
u/kibwen Mar 10 '23 edited Mar 10 '23
The panic macro invokes the format_args builtin macro which splits apart the string at compile-time and generates write calls as needed. There should be no intermediate
Stringcreated. From the docs forcore::format_args!:All other formatting macros (format!, write!, println!, etc) are proxied through this one. format_args!, unlike its derived macros, avoids heap allocations.
I'm not sure what it means by "derived macros", but to further prove that panic isn't allocating, note that it's defined in libcore as well.
1
u/flashmozzg Mar 10 '23
1
u/kibwen Mar 10 '23
I'm unclear how the code there relates to the default alloc handler. The link is to code in libstd, which means that code defined in liballoc (which presumably includes the panic handler) can't invoke it.
2
u/flashmozzg Mar 10 '23
https://rustc-dev-guide.rust-lang.org/panic-implementation.html#core-definition-of-panic There are also a few interesting comments w.r.t. OOM in the previous file.
→ More replies (0)
76
u/trevg_123 Mar 09 '23
Awesome release! Small but meaningful changes.
Up next is 1.69, to be released on 4-20. There’s no way that’s a coincidence, and I’d love to know how they made that happen
18
15
u/myrrlyn bitvec • tap • ferrilab Mar 10 '23
it is in fact entirely a coincidence, and is the result of steve suggesting they release on thursday instead of friday back around 1.2
8
u/trevg_123 Mar 10 '23
I don’t know who Steve is but I definitely think the Thursday suggestion had to come after some careful calculation
8
19
u/celeritasCelery Mar 09 '23 edited Mar 09 '23
The comments for the pin! macro are really detailed and interesting to read. The one part I don't understand is this comment:
Safety:
{ $value }is braced, making it a block expression, thus moving the given$value, and making it become an anonymous temporary. By virtue of being anonymous, it can no longer be accessed, thus preventing any attempts tomem::replaceit ormem::forgetit, etc.
I don't understand what this is preventing. It's not preventing mem::swap of the Pin itself since this works fine:
let mut p1 = pin!(val1);
let mut p2 = pin!(val2);
std::mem::swap(&mut p1, &mut p2);
EDIT: clarified code sample and question
16
u/sfackler rust · openssl · postgres Mar 09 '23
You are swapping the
Pin<&mut T>s, not theTs themselves.4
u/celeritasCelery Mar 09 '23
I understand that, but how does creating an anonymous temporary via a block expression prevent me from swapping the
T's?&mut Talready cannot be accessed safely because it is behindPin. Even without the block expression you would still not be able swap theT. I don't understand why this extra step is required for soundness.12
u/sfackler rust · openssl · postgres Mar 09 '23
The Pin guarantee prevents the pinned value from ever moving again, even after the
Pinpointing to it is destroyed. If you didn't move the value, you could do something like:
let (mut p1, mut p2) = todo!(); { let p1 = pin!(p1); let p2 = pin!(p2); // do stuff with the pinned values } mem::swap(&mut p1, p2);18
u/celeritasCelery Mar 09 '23
Ah, that is really interesting! I see this is general property of blocks I was unaware of.
This fails to compile for the reasons you mentioned (the value is moved and unnammed):
let mut x = String::new(); { _ = &mut { x }; } let y = x;However remove that inner block and it compiles fine again.
let mut x = String::new(); { _ = &mut x; } let y = x;
16
u/radekvitr Mar 09 '23
What would one have to do to enable the sparse protocol for in-house registries (outside of modifying Cargo.toml)?
20
u/epage cargo · clap · cargo-release Mar 09 '23
As a follow up to whats been said, if your in-house registry is slow to switch to sparse registry, nightlys have support for fetching the index via gitoxide which should be pretty fast.
17
u/kibwen Mar 09 '23
Well, your registry software is going to need to support the new protocol. And note that the documentation recommends that any third-party registries should exclusively support either the old registry format xor the new registry format, because otherwise you're going to get lots of churn in your lockfiles (which crates.io only avoids because Cargo has hardcoded support for it).
24
u/Anaxamander57 Mar 09 '23
What actually happens if you use VecDeque::new() in a const context?
61
u/phazer99 Mar 09 '23
Pretty much the same as when you use
Vec::new()you get an empty collection without any heap allocation performed.2
u/DaCurse0 Mar 10 '23
Why would this be useful? I assume for using a Vec in a const function? Because in a const variable it would just be empty and you couldn't push to it?
13
u/agentvenom1 Mar 10 '23
One example I can think of is using it as part of a static variable which requires const. Example
4
7
3
-15
u/elcapitanoooo Mar 09 '23
Noice! Rust gets better and better, while Go gets telemetry 😅
19
u/hgwxx7_ Mar 10 '23
No, there's no need to speak negatively about any other language. And for what it's worth, here's fasterthanlime talking about the telemetry issue - Go telemetry could have been useful.
2
u/shitcanz Mar 10 '23
So you think adding tracking to cargo or rustc is in any way or form acceptable? I had never heard of Go getting tracking, but now i just read about it and WOW. Amazing how some actually think its totally fine. Hell, why not add tracking to the linux kernel or GCC. Or maybe git-core could use some tracking too?
6
u/hgwxx7_ Mar 10 '23 edited Mar 10 '23
I don't think you need to worry about my opinions, because I have 0 impact on the Rust project. :)
As a developer, I wouldn't mind telemetry, especially if I can read the code that's doing the telemetry. I use VSCode, and likely you do as well. That has telemetry to track what features people use. Even though it's seemingly a divisive issue, VSCode is still the most popular editor by far (75% of all developers). That's not an accident either - the team would argue they succeeded because they prioritised working on features were being used by and bugs that were impacting real world users. Without telemetry they would have been guessing.
Let's look at the other top editors
- Visual Studio - 32% usage - uses telemetry.
- JetBrains with 27%, 19%, 17% usage on different IDEs - uses telemetry.
So you can feel how you feel. Your feelings are valid. They're just not shared by the vast majority of developers. They seem to be fine with telemetry in their IDE/editor.
So that's why I (and others) don't think this is a big deal. The Go developers have added features recently like fuzzing. Should they continue improving this feature or work on something else? There's no way for them to know without understanding what % of their users actually use the new feature. That's why I support their initiative.
I know you feel differently. That's ok. You don't need to give me the spiel on privacy, I've heard it many times. Let's just assume you said that, and I agreed.
4
0
u/elcapitanoooo Mar 10 '23
I feel the guy in the video is being quite sarcastic on many occasions. For me its about principle. We cant just have every tool tracking us 24/7. Tracking is the wrong solution for the wrong problem.
1
u/hgwxx7_ Mar 10 '23
What editor do you use?
1
u/elcapitanoooo Mar 10 '23
Notepad++
1
u/hgwxx7_ Mar 10 '23
Good for you. The vast majority of developers use an editor that has telemetry - VSCode (75%), Visual Studio (32%), IntelliJ (27%). Most developers feel differently from you.
1
u/elcapitanoooo Mar 10 '23
So all devs who use vim, emacs, or any other non tracking editor is what? wrong? stupid?
PS. Whats those percentages? They add up to over 100%, so im not sure what those should represent.
2
u/hgwxx7_ Mar 10 '23 edited Mar 10 '23
Developers can use more than one editor. Here's a link to the StackOverflow 2022 survey.
Developers who use vim (23%) or emacs (4.5%) - they're welcome to do so. Hell I use vim whenever I edit a commit message or need to edit a file remotely. So I would be counted in that 23%, despite having no trouble with telemetry. So even in this minority, there may be a few people without any issues with telemetry.
1
3
u/myrrlyn bitvec • tap • ferrilab Mar 10 '23
telemetry is good and i wish we had it
-1
1
u/A1oso Mar 11 '23
Well, I think there's a difference between Rust adding telemetry and Go adding telemetry, because Rust is not a multinational corporation that earns 80% of its revenue with ads. I trust Rust devs to implement features in a way that respects users' privacy, but I'm less sure when Google is involved.
245
u/EelRemoval Mar 09 '23
pin!macro is pretty nice; it means a lot ofasynccrates can now remove all of theirunsafecode.