update

Author: yijunyu

.gitattributes

@@ -0,0 +1,2 @@
+*.mp4 filter=lfs diff=lfs merge=lfs -text
+videos/2024-03-26/huawei_and_rust.mp4 filter=lfs diff=lfs merge=lfs -text

.gitignore

@@ -0,0 +1,3 @@
+_site
+.bundle
+vendor

Gemfile

@@ -0,0 +1,16 @@
+source "https://rubygems.org"
+gem "jekyll", "~> 4.3.1"
+
+# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
+# and associated library.
+platforms :mingw, :x64_mingw, :mswin, :jruby do
+  gem "tzinfo", ">= 1", "< 3"
+  gem "tzinfo-data"
+end
+
+# Performance-booster for watching directories on Windows
+gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
+
+# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
+# do not have a Java counterpart.
+gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby]

Gemfile.lock

@@ -0,0 +1,77 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.8.1)
+      public_suffix (>= 2.0.2, < 6.0)
+    colorator (1.1.0)
+    concurrent-ruby (1.2.0)
+    em-websocket (0.5.3)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0)
+    eventmachine (1.2.7)
+    ffi (1.15.5)
+    forwardable-extended (2.6.0)
+    google-protobuf (3.21.12)
+    http_parser.rb (0.8.0)
+    i18n (1.12.0)
+      concurrent-ruby (~> 1.0)
+    jekyll (4.3.2)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      em-websocket (~> 0.5)
+      i18n (~> 1.0)
+      jekyll-sass-converter (>= 2.0, < 4.0)
+      jekyll-watch (~> 2.0)
+      kramdown (~> 2.3, >= 2.3.1)
+      kramdown-parser-gfm (~> 1.0)
+      liquid (~> 4.0)
+      mercenary (>= 0.3.6, < 0.5)
+      pathutil (~> 0.9)
+      rouge (>= 3.0, < 5.0)
+      safe_yaml (~> 1.0)
+      terminal-table (>= 1.8, < 4.0)
+      webrick (~> 1.7)
+    jekyll-sass-converter (3.0.0)
+      sass-embedded (~> 1.54)
+    jekyll-watch (2.2.1)
+      listen (~> 3.0)
+    kramdown (2.4.0)
+      rexml
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
+    liquid (4.0.4)
+    listen (3.8.0)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    mercenary (0.4.0)
+    pathutil (0.16.2)
+      forwardable-extended (~> 2.6)
+    public_suffix (5.0.1)
+    rake (13.0.6)
+    rb-fsevent (0.11.2)
+    rb-inotify (0.10.1)
+      ffi (~> 1.0)
+    rexml (3.2.5)
+    rouge (4.0.1)
+    safe_yaml (1.0.5)
+    sass-embedded (1.58.0)
+      google-protobuf (~> 3.21)
+      rake (>= 10.0.0)
+    terminal-table (3.0.2)
+      unicode-display_width (>= 1.1.1, < 3)
+    unicode-display_width (2.4.2)
+    webrick (1.8.1)
+
+PLATFORMS
+  x64-mingw-ucrt
+  x86_64-linux
+
+DEPENDENCIES
+  http_parser.rb (~> 0.6.0)
+  jekyll (~> 4.3.1)
+  tzinfo (>= 1, < 3)
+  tzinfo-data
+  wdm (~> 0.1.1)
+
+BUNDLED WITH
+   2.3.5

README.md

@@ -0,0 +1,14 @@
+# Trusted Programming
+
+If you want to run it locally, install it first. Then:
+
+```bash
+$ bundle config set --local path 'vendor/bundle'
+$ bundle install
+```
+
+When it's all done, you can run it locally like this:
+
+```bash
+$ bundle exec jekyll serve
+```

_config.yml

@@ -0,0 +1,22 @@
+title: Trusted Programming
+description: >- 
+  As a leading telecommunications company on a global scale, Huawei is
+  dedicated to the development of dependable software systems. To achieve this
+  goal, our team of developers relies heavily on the support provided by Rust
+  programming language. As a founding member of the Rust Foundation, Huawei is
+  fully committed to the growth and prosperity of the Rust community. To
+  demonstrate our commitment, we have created automated tools to transform C code
+  into a safer Rust code, and are continuously contributing to the improvement
+  and expansion of Rust's features. 
+baseurl: ""
+url: "https://trusted-programming.github.io"
+
+collections:
+  contributions:
+    output: false
+  projects:
+    output: false
+  team:
+    output: false
+  research_labs:
+    output: false

_contributions/async-drop.md

@@ -0,0 +1,17 @@
+---
+name: Async Drop
+area: compiler
+status: 
+  label: in-progress
+  css_class: attention
+buttons:
+---
+Support asynchronous destruction of objects running out of scope:
+
+1. Implement code generation for asynchronous drop
+
+2. Implement prevention measures for running asynchronous drop synchronously
+
+3. Implement type system pre-requisites for (2) if necessary - type system refactoring, linear types
+
+4. Implement any other features in rustc compiler that will help Rust language team to make a decision about including async drop to the language

_contributions/atomic-memcpy.md

@@ -0,0 +1,32 @@
+---
+name: Atomic memcpy
+area: library
+status:
+  label: in-progress
+  css_class: attention
+buttons:
+  - label: Atomic memcpy RFC
+    link: https://github.com/m-ou-se/rfcs/blob/atomic-memcpy/text/3301-atomic-memcpy.md
+---
+It's currently not possible to implement an efficient and strictly correct *sequence lock* in Rust,
+which is a very important low level synchronization primitive.
+
+Reading the data from a sequence lock relies on the ability to read data that might be
+concurrently modified, checking afterwards if a data race occured (by checking an atomic sequence counter),
+and only then *using* the data after the check.
+(See [the RFC](https://github.com/m-ou-se/rfcs/blob/atomic-memcpy/text/3301-atomic-memcpy.md#the-problem) for a detailed explanation.)
+
+However, in the memory model of Rust (and C++),
+reading data that is concurrently modified results in a data race (undefined behavior) *immdiately*,
+not just when using the data later.
+
+Crates like `seqlock` work around this by using `ptr::read_volatile`, but the correctness is debatable.
+
+C++'s [P1478](https://wg21.link/p1478r7) adds
+`atomic_load_per_byte_memcpy` and `atomic_store_per_byte_memcpy` to provide a solution for that problem.
+Rust should have something similar, but something that fits better into Rust's type and safety system.
+
+[Rust RFC 3301](https://github.com/m-ou-se/rfcs/blob/atomic-memcpy/text/3301-atomic-memcpy.md) is
+a proposal for a generic type `AtomicPerByte<T>` that allows for concurrent reads and writes that do not result in undefined behavior,
+while still allowing tearing to allow reads and writes of any size.
+It leverages the `MaybeUninit<T>` type to represent types in potentially invalid (teared) state.

_contributions/btreemap-cursors.md

@@ -0,0 +1,20 @@
+---
+name: Cursor support for BTreeMap
+area: library
+status: 
+  label: in-progress
+  css_class: attention
+buttons:
+  - label: API Change Proposal
+    link: https://github.com/rust-lang/libs-team/issues/141
+---
+One of the fundamental properties of `BTreeMap` is that it maintains elements in sorted order and 
+enables efficient element lookup in `O(log(N))` time. However the current API is overly fitted 
+towards a key-value API like a HashMap and fails to expose the ability to make queries about 
+"nearby" keys. For example, finding the first element whose key is greater than X.
+
+This proposal adds `Cursor` and `CursorMut` types to `BTreeMap` based on  [similar][cursor] 
+[types][cursor_mut] for `LinkedList`.
+
+[cursor]: https://doc.rust-lang.org/nightly/std/collections/linked_list/struct.Cursor.html
+[cursor_mut]: https://doc.rust-lang.org/nightly/std/collections/linked_list/struct.CursorMut.html

_contributions/cg_gcc.md

@@ -0,0 +1,10 @@
+---
+name: rustc_codegen_gcc
+area: compiler
+status: 
+  label: in-progress
+  css_class: attention
+buttons:
+---
+
+`rustc_codegen_gcc` adds support for GCC as backend for the Rust compiler. It'll allow to support a lot more of compilation targets while also benefiting from GCC advantages.