Especially when documenting the use of `0`, since zero looks very
similar to `O` in fonts not meant for displaying code.
Other literal characters, traits, etc should also use code formatting.
This change makes this documentation more internally consistent.
Before this change, circled is the character I was using this documentation to find out about and that confused me when it wasn't immediately clear what character it was:
<img width="1013" alt="screen shot 2015-09-28 at 10 13 31 pm" src="https://cloud.githubusercontent.com/assets/193874/10154708/c70815fe-6638-11e5-9acc-57c73a524203.png">
After this change:
<img width="981" alt="screen shot 2015-09-28 at 11 26 35 pm" src="https://cloud.githubusercontent.com/assets/193874/10154710/ce73eeb2-6638-11e5-98f7-902f58679316.png">
I ran `make check-docs` and didn't break anything ⭐
Especially when documenting the use of `0`, since zero looks very
similar to `O` in fonts not meant for displaying code.
Other literal characters, traits, etc should also use code formatting.
This change makes this documentation more internally consistent.
This commit updates the compiler to not attempt to use jemalloc for platforms
where jemalloc is never enabled. Currently the compiler attempts to link in
jemalloc based on whether `--disable-jemalloc` was specified at build time for
the compiler itself, but this is only the right decision for the host target,
not for other targets.
This still leaves a hole open where a set of target libraries are downloaded
which were built with `--disable-jemalloc` and the compiler is unaware of that,
but this is a pretty rare case so it can always be fixed later.
By putting an "unreachable" instruction into the default arm of a switch
instruction we can let LLVM know that the match is exhaustive, allowing
for better optimizations.
For example, this match:
```rust
pub enum Enum {
One,
Two,
Three,
}
impl Enum {
pub fn get_disc(self) -> u8 {
match self {
Enum::One => 0,
Enum::Two => 1,
Enum::Three => 2,
}
}
}
```
Currently compiles to this on x86_64:
```asm
.cfi_startproc
movzbl %dil, %ecx
cmpl $1, %ecx
setne %al
testb %cl, %cl
je .LBB0_2
incb %al
movb %al, %dil
.LBB0_2:
movb %dil, %al
retq
.Lfunc_end0:
```
But with this change we get:
```asm
.cfi_startproc
movb %dil, %al
retq
.Lfunc_end0:
```
This was non-obvious to me: with no example, I assumed `Electron {}` and
didn't know what else to try when it didn't work. The correct form is
weird because it looks like you're assigning the struct name rather than
an instance of the struct.
r? @steveklabnik
the example for `find` was misleading in that it fails to mention the result is either `None` or `Some` containing only the first match. Further confusing the issue is the `println!` statement, "We got some numbers!"
As discussed in the referenced issues, this PR makes rustc emit `__imp_<symbol>` stubs for all public static data to ensure smooth linking in on `-windows-msvc` targets.
Resolves#26591, cc #27438
This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).
cc #27743
This wasn't complete (you need a `./configure`), and it is already
documented well in the main README.
Also adds a reference to the books that this also generates.
This was non-obvious to me: with no example, I assumed `Electron {}` and
didn't know what else to try when it didn't work. The correct form is
weird because it looks like you're assigning the struct name rather than
an instance of the struct.
This adds a new target, `x86_64-rumprun-netbsd`, and related changes to `std`.
Rumprun is a unikernel platform that provides a POSIX-y interface. For the most part, rumprun uses NetBSD's libc and drivers, therefore `target_os` is `netbsd`. However, being a unikernel, rumprun does not support process management, signals or virtual memory, so related functions might fail at runtime. For this reason, stack guards are disabled in `std`.
To support conditional compilation, `target_env` is set to `rumprun`. Maybe `target_vendor` would be technically more fitting, but it doesn't seem to be worth the hassle.
Code for rumprun is always cross-compiled, it uses always static linking and needs a custom linker. The target makes use of the newly introduced `no_default_libs` flag, as the rumprun linker will otherwise not use the correct search path.
