The failure functions are generic, meaning they're candidates for getting
inlined across crates. This has been happening, leading to monstrosities like
that found in #11549. I have verified that the codegen is *much* better now that
we're not inlining the failure path (the slow path).
Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes#9510Closes#11533
The failure functions are generic, meaning they're candidates for getting
inlined across crates. This has been happening, leading to monstrosities like
that found in #11549. I have verified that the codegen is *much* better now that
we're not inlining the failure path (the slow path).
Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes#9510Closes#11533
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
This work is done by execute these commands manually:
$ po4a --copyright-holders="The Rust Project Developers" \
--package-name="Rust" \
--package-version="0.10-pre" \
-M UTF-8 -L UTF-8 \
doc/po4a.conf
$ for f in doc/po/**/*.po; do
> msgattrib --untranslated $f -o $f.strip
> if [ -e $f.strip ]; then
> mv $f.strip $f
> else
> rm $f
> fi
> done
It should be managed by the build system automatically to use in our
translation workflow, but I've not yet done that.
At least one mostly-translated (over 80% translation rate) document is needed to test the translation workflow, so I'll working on Japanese translation.
cc @cmr
Temporary change to issue #10535. Requires significant re-factoring to search completely based on the index paths. For example searching for "File::" in this fix will return no results. Still need to search completely based on path (rather than name's + types) to completely fix. Will continue to work this
This work is done by execute these commands manually:
$ po4a --copyright-holder="The Rust Project Developers" \
--package-name="Rust" \
--package-version="0.10-pre" \
-M UTF-8 -L UTF-8 \
doc/po4a.conf
$ for f in doc/po/**/*.po; do
> msgattrib --translated $f -o $f.strip
> if [ -e $f.strip ]; then
> mv $f.strip $f
> else
> rm $f
> fi
> done
It should be managed by the build system automatically to use in our
translation workflow, but I've not yet done that.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Made temporary changes to include multiple keywords in rustdoc search
Implemented search based on multiple keywords
Added some commenting and house cleaning
Added path searching to rustdoc
The official documentation sorely needs an explanation of the rust runtime and what it is exactly, and I want this guide to provide that information.
I'm unsure of whether I've been too light on some topics while too heavy on others. I also feel like a few things are still missing. As always, feedback is appreciated, especially about things you'd like to see written about!
