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).
These functions are of little utility outside a small subset of use cases. If people need them for their own projects then they can use their own bindings for libm (which aren't hard to make).
This is unnecessary and also leads to a bug: When the user specifies
```
#[crate_type = "rlib"];
```
rustpkg still creates a dylib.
Also it's good not to duplicate functionality. `build_session_options` handles this just fine.
Use a lookup table, SHIFT_MASK_TABLE, that for every possible four
bit prefix holds the number of times the value should be right shifted and what
the right shifted value should be masked with. This way we can get rid of the
branches which in my testing gives approximately a 2x speedup.
Dead code pass now explicitly checks for `#[allow(dead_code)]` and
`#[lang=".."]` attributes on items and marks them as live if they have
those attributes. The former is done so that if we want to suppress
warnings for a group of dead functions, we only have to annotate the
"root" of the call chain.
Close#11380 and #11440.
Dead code pass now explicitly checks for `#[allow(dead_code)]` and
`#[lang=".."]` attributes on items and marks them as live if they have
those attributes. The former is done so that if we want to suppress
warnings for a group of dead functions, we only have to annotate the
"root" of the call chain.
Since reader::vuint_at() returns a result of type reader::Res it makes sense
to make it public.
Due to rust's current behavior of externally referenced private structures,
https://github.com/mozilla/rust/issues/10573, you could still use the result and
assign it to a variable if you let the compiler do the type assignment,
but you could not explicitly annotate a variable to hold a reader::Res.
a30d61b05a removed all of the trailing whitespace in doc/index.md.
Unfortunately, that trailing whitespace was actually markdown syntax for
line breaks.
