Avec Rust 1.67.0, un attribut must_use sur les fonctions asynchrones fait maintenant ce que vous attendez

Avec Rust 1.67.0, un attribut must_use sur les fonctions asynchrones fait désormais ce à quoi vous vous attendez.
Les types entiers ont maintenant des méthodes de logarithme (entier) : ilog, ilog10, ilog2.

#[must_use] efficace sur async fn

Les fonctions [C]async[/] annotées avec #[must_use] appliquent désormais cet attribut à la sortie de l'impl Future renvoyé. Le trait Future lui-même est déjà annoté avec #[must_use], donc tous les types implémentant Future sont automatiquement #[must_use], ce qui signifiait qu'auparavant il n'y avait aucun moyen d'indiquer que la sortie de Future est elle-même significative et devrait être utilisée dans certains chemin.

Avec 1.67, le compilateur avertira désormais si la sortie n'est pas utilisée d'une manière ou d'une autre.
Code:

1 2 3 4 5 6 #[must_use] async fn bar() -> u32 { 0 } async fn caller() { bar().await; }
Citation:

Envoyé par affichage à l'écran

warning: unused output of future returned by `bar` that must be used
--> src/lib.rs:5:5
|
5 | bar().await;
| ^^^^^^^^^^^
|
= note: `#[warn(unused_must_use)]` on by default

Implémentation mise à jour de std::sync::mpsc

La bibliothèque standard de Rust avait un canal multi-producteur et mono-consommateur bien avant la version 1.0, mais dans cette version, l'implémentation est commutée pour être basée sur le canal crossbeam. Cette version ne contient aucune modification de l'API, mais la nouvelle implémentation corrige un certain nombre de bogues et améliore les performances et la maintenabilité de l'implémentation.

Les utilisateurs ne devraient pas remarquer de changements significatifs de comportement à partir de cette version.

API stabilisées

{integer}::checked_ilog
{integer}::checked_ilog2
{integer}::checked_ilog10
{integer}::ilog
{integer}::ilog2
{integer}::ilog10
NonZeroU*::ilog2
NonZeroU*::ilog10
NonZero*::BITS

Pièce jointe 633242

Rust dans l'actualité

« La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ »

Mark Russinovich de Microsoft a déclaré au troisième trimestre de l’année précédente que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA a récemment trouvé un contradicteur.

Sans surprise, le créateur du langage C++ a déclaré : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »

Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.

« Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.

L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 #include <type_traits> #include <utility> #include <assert.h> #include <stddef.h> enum NoRefs {}; enum HasMutRef {}; enum HasRefs {}; template <class T, typename Mode> class Own; template <class T> class MutRef; template <class T> class Ref; template <class T, typename... Args> inline Own<T, NoRefs> make(Args... args) { return Own<T, NoRefs>(std::forward<Args>(args)...); } template <class T> inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) { return Own<T, NoRefs>(std::move(own)); } template <class T> inline Own<T, NoRefs> consume(Own<T, HasRefs> own) { return Own<T, NoRefs>(std::move(own)); } template <class T> std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) { T* t = own.t_; own.t_ = nullptr; return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t)); } template <class T> std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) { T* t = own.t_; own.t_ = nullptr; return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t)); } // No refs exist. template <class T> class [[clang::trivial_abi]] Own<T, NoRefs> { public: template <typename... Args> Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {} ~Own() { delete t_; } Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; } T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } private: friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref); friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own); friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); Own(Own<T, HasMutRef>&& own) : t_(own.t_) {} Own(Own<T, HasRefs>&& own) : t_(own.t_) {} T* t_; }; // A mut ref exists. template <class T> class [[clang::trivial_abi]] Own<T, HasMutRef> { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } private: friend class Own<T, NoRefs>; Own(T* t) : t_(t) {} ~Own() {} T* t_; }; // Non-mut refs exist. template <class T> class [[clang::trivial_abi]] Own<T, HasRefs> { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } Ref<T> ref() { return Ref<T>(t_, &count_); } private: friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); explicit Own(T* t) : t_(t) {} ~Own() { assert(count_ == 0u); } T* t_; uint32_t count_; }; template <class T> class MutRef { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } ~MutRef() = default; MutRef(MutRef&& other) : t_(other.t_) {} private: friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); MutRef(T* t) : t_(t) {} T* t_; }; template <class T> class Ref { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } ~Ref() { --(*count_); } Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); } Ref(Ref&& other) : t_(other.t_), count_(other.count_) {} private: friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); } T* t_; uint32_t* count_; }; MutRef<int> Borrows(MutRef<int> i) { (*i)++; return i; } TEST(Borrow, HelloWorld) { // Can't do this. The HasMutRefs type is not destructible outside of // consume()in order to have compiler check it is re-owned, but it won't // compile. To pass the HasMutRefs to consume() it has to be destroyed both // inside and outside of consume(). This is true even if trivial_abi is // used and only one destructor would actually run. Own<int, NoRefs> i = make<int>(5); auto& hasmut = mut(std::move(i)); MutRef<int> ref = Borrows(std::move(hasmut.second)); Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref)); }
Le projet Chromium va prendre en charge l'utilisation de bibliothèques Rust tierces à partir de C++

L'objectif de l'intégration de Rust dans Chromium est de fournir un moyen plus simple (pas d'IPC) et plus sûr (C++ moins complexe dans l'ensemble, pas de bogues de sécurité de la mémoire dans une sandbox) de satisfaire la règle des deux, afin d'accélérer le développement (moins de code à écrire, moins de documents de conception, moins d'examens de sécurité) et d'améliorer la sécurité (augmentation du nombre de lignes de code sans bogues de sécurité de la mémoire, diminution de la densité de bogues du code) de Chrome. De plus, la société est convaincue que nous pouvons utiliser des bibliothèques Rust tierces pour atteindre cet objectif.

Rust a été développé par Mozilla spécifiquement pour être utilisé dans l'écriture d'un navigateur, il est donc tout à fait approprié que Chromium commence enfin à s'appuyer sur cette technologie également. Merci Mozilla pour votre énorme contribution à l'industrie des logiciels de systèmes. Rust a été une preuve incroyable que nous devrions être en mesure d'attendre d'un langage qu'il offre la sécurité tout en étant performant.

Nous savons que C++ et Rust peuvent jouer ensemble de manière agréable, grâce à des outils comme cxx, autocxx bindgen, cbindgen, diplomat, et (expérimental) crubit. Cependant, il y a aussi des limites. Nous pouvons nous attendre à ce que la forme de ces limitations change avec le temps grâce à des outils nouveaux ou améliorés, mais les décisions et les descriptions ici sont basées sur l'état actuel de la technologie.

Source : Rust