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
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!
This is a patch for #8005, thanks @lfairy for the hint.
It seems like `block.expr` is None, if the last line of a function has a semi colon (= it ends with a statement).
@kmcallister does this error message cover the intended use cases?
I'm not sure about the message, the wording and the span could probably be improved.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with \<V0>, \<VI0>
and \<VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with <V0>, <VI0>
and <VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
The gamma and bessel functions are of little utility outside a small specialized subset of use cases, and so they don't really make sense for inclusion in the standard library. The only reason they were included in the first place was to mirror libm, which is not a very good justification. If people need them for their own projects then they can make their own bindings to libm (which isn't too hard).