Currently, immediate values are copied into an alloca only to have an
addressable storage so that it can be used with memcpy. Obviously we
can skip the memcpy in this case.
This is much faster for strings, and eventually when there is a
buffered reader of some sort, will be much faster for files.
Reading example.json 100 times before was around 1.18s.
After:
- reading from string 0.68s
- reading from file 1.08s (extra time is all in io::Reader)
Also:
- fixes#7611 - error when parsing strings and we hit EOF
- updates definition of whitespace in json should only be the 4 ascii whitespace chars
All of the examples were still using `core::` instead of `std::` and needed a `use std::rand;` at the top to compile
Most of the examples had
`rng = rand::rng();`
instead of
`let mut rng = rand::rng();`
This is much faster for strings, and eventually when there is a
buffered reader of some sort.
Reading example.json 100 times before was around 1.18s.
After:
- reading from string 0.68s
- reading from file 1.08s (extra time is all in io::Reader)
Added Add and Sub traits for pointer arithmetic. Any type that is a ```std::num::Int``` can be added to or subtracted from a pointer. Also my additions did not require any unsafe code, and the operators themselves are safe. Fixes#2122.
The examples were still using `core::` instead of `std::`
All of the examples needed a `use std::rand;` at the top to compile
Most of the examples had
`rng = rand::rng();`
instead of
`let mut rng = rand::rng();`
When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)
When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.
The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
Fixes#3225 (at least in terms of mitigating the multiple library
problem by proactively warning the user about it.)
r? @graydon, @nikomatsakis, @pcwalton, or @catamorphism
Sorry this is so huge, but it's been accumulating for about a month. There's lots of stuff here, mostly oriented toward enabling multithreaded scheduling and improving compatibility between the old and new runtimes. Adds task pinning so that we can create the 'platform thread' in servo.
[Here](e1555f9b56/src/libstd/rt/mod.rs (L201)) is the current runtime setup code.
About half of this has already been reviewed.
The free-standing functions in f32, f64, i8, i16, i32, i64, u8, u16,
u32, u64, float, int, and uint are replaced with generic functions in
num instead.
This means that instead of having to know everywhere what the type is, like
~~~
f64::sin(x)
~~~
You can simply write code that uses the type-generic versions in num instead, this works for all types that implement the corresponding trait in num.
~~~
num::sin(x)
~~~
Note 1: If you were previously using any of those functions, just replace them
with the corresponding function with the same name in num.
Note 2: If you were using a function that corresponds to an operator, use the
operator instead.
Note 3: This is just https://github.com/mozilla/rust/pull/7090 reopened against master.
Apparently yesterday wasn't my day, and I forgot to add the changes to
all the tests apparently, and in the end forgot the docs extra much.
Please documentation, forgive me, I really do love you, I hope you
forgive me.
Next time we'll meet tutorial, I promise to bring cookies and tea. I
really want to be best-friends-forever with you, <3.
XOXO
This improves things like doc comment handling when you press Enter and
making using `gf` or `<C-W>f` work on a `use x;` statement in the
current directory.
- Add fold support (NOT turned on by default)
- Highlight `::` by default
- Support the common `NOTE` as an important note
- Highlight `assert!` and `fail!` differently
- Don't highlight `deriving(...)` except in `#[...]`
Basically, one may just do:
MemoryMap::new(16, ~[
MapExecutable,
MapReadable,
MapWritable
])
And executable+readable+writable chunk of at least 16 bytes size will be
allocated and freed with the result of `MemoryMap::new`.
This is a small follow-up fix to the previous commit: I needed
to quote the right-hand side of the definition for the variable
MATCHES, to handle the case where there are more than one previously
installed libraries in the target directory.
