Skip to content

Commit 711f11e

Browse files
committed
Auto merge of #30544 - steveklabnik:rollup, r=steveklabnik
- Successful merges: #30251, #30461, #30465, #30473, #30529, #30537, #30539, #30541, #30543 - Failed merges:
2 parents 8037e62 + 944b337 commit 711f11e

12 files changed

+34
-515
lines changed

CONTRIBUTING.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -238,7 +238,7 @@ are:
238238
* Don't be afraid to ask! The Rust community is friendly and helpful.
239239

240240
[gdfrustc]: http://manishearth.github.io/rust-internals-docs/rustc/
241-
[gsearchdocs]: https://www.google.de/search?q=site:doc.rust-lang.org+your+query+here
241+
[gsearchdocs]: https://www.google.com/search?q=site:doc.rust-lang.org+your+query+here
242242
[rif]: http://internals.rust-lang.org
243243
[rr]: https://doc.rust-lang.org/book/README.html
244244
[tlgba]: http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/

configure

+11-8
Original file line numberDiff line numberDiff line change
@@ -521,15 +521,18 @@ then
521521
# if configure is running in an interactive bash shell. /usr/bin/env
522522
# exists *everywhere*.
523523
BIN_TO_PROBE="$SHELL"
524-
if [ -z "$BIN_TO_PROBE" -a -e "/usr/bin/env" ]; then
525-
BIN_TO_PROBE="/usr/bin/env"
524+
if [ ! -r "$BIN_TO_PROBE" ]; then
525+
if [ -r "/usr/bin/env" ]; then
526+
BIN_TO_PROBE="/usr/bin/env"
527+
else
528+
warn "Cannot check if the userland is i686 or x86_64"
529+
fi
530+
fi
531+
file -L "$BIN_TO_PROBE" | grep -q "x86[_-]64"
532+
if [ $? != 0 ]; then
533+
msg "i686 userland on x86_64 Linux kernel"
534+
CFG_CPUTYPE=i686
526535
fi
527-
if [ -n "$BIN_TO_PROBE" ]; then
528-
file -L "$BIN_TO_PROBE" | grep -q "x86[_-]64"
529-
if [ $? != 0 ]; then
530-
CFG_CPUTYPE=i686
531-
fi
532-
fi
533536
fi
534537

535538

src/doc/book/error-handling.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -182,7 +182,7 @@ analysis is the only way to get at the value stored inside an `Option<T>`. This
182182
means that you, as the programmer, must handle the case when an `Option<T>` is
183183
`None` instead of `Some(t)`.
184184

185-
But wait, what about `unwrap`,which we used [`previously`](#code-unwrap-double)?
185+
But wait, what about `unwrap`, which we used [previously](#code-unwrap-double)?
186186
There was no case analysis there! Instead, the case analysis was put inside the
187187
`unwrap` method for you. You could define it yourself if you want:
188188

src/doc/book/no-stdlib.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -151,7 +151,7 @@ extern fn panic_fmt(args: &core::fmt::Arguments,
151151
# fn main() {}
152152
```
153153

154-
Note that there is one extra lang item here which differs from the examples
154+
Note that there is one lang item here whose signature differs from the examples
155155
above, `panic_fmt`. This must be defined by consumers of libcore because the
156156
core library declares panics, but it does not define it. The `panic_fmt`
157157
lang item is this crate's definition of panic, and it must be guaranteed to

src/doc/complement-design-faq.md

+1-184
Original file line numberDiff line numberDiff line change
@@ -1,186 +1,3 @@
11
% The Rust Design FAQ
22

3-
This document describes decisions that were arrived at after lengthy discussion and
4-
experimenting with alternatives. Please do not propose reversing them unless
5-
you have a new, extremely compelling argument. Note that this document
6-
specifically talks about the *language* and not any library or implementation.
7-
8-
A few general guidelines define the philosophy:
9-
10-
- [Memory safety][mem] must never be compromised
11-
- [Abstraction][abs] should be zero-cost, while still maintaining safety
12-
- Practicality is key
13-
14-
[mem]: http://en.wikipedia.org/wiki/Memory_safety
15-
[abs]: http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29
16-
17-
# Semantics
18-
19-
## Data layout is unspecified
20-
21-
In the general case, `enum` and `struct` layout is undefined. This allows the
22-
compiler to potentially do optimizations like re-using padding for the
23-
discriminant, compacting variants of nested enums, reordering fields to remove
24-
padding, etc. `enum`s which carry no data ("C-like") are eligible to have a
25-
defined representation. Such `enum`s are easily distinguished in that they are
26-
simply a list of names that carry no data:
27-
28-
```
29-
enum CLike {
30-
A,
31-
B = 32,
32-
C = 34,
33-
D
34-
}
35-
```
36-
37-
The [repr attribute][repr] can be applied to such `enum`s to give them the same
38-
representation as a primitive. This allows using Rust `enum`s in FFI where C
39-
`enum`s are also used, for most use cases. The attribute can also be applied
40-
to `struct`s to get the same layout as a C struct would.
41-
42-
[repr]: reference.html#ffi-attributes
43-
44-
## There is no GC
45-
46-
A language that requires a GC is a language that opts into a larger, more
47-
complex runtime than Rust cares for. Rust is usable on bare metal with no
48-
extra runtime. Additionally, garbage collection is frequently a source of
49-
non-deterministic behavior. Rust provides the tools to make using a GC
50-
possible and even pleasant, but it should not be a requirement for
51-
implementing the language.
52-
53-
## Non-`Sync` `static mut` is unsafe
54-
55-
Types which are [`Sync`][sync] are thread-safe when multiple shared
56-
references to them are used concurrently. Types which are not `Sync` are not
57-
thread-safe, and thus when used in a global require unsafe code to use.
58-
59-
[sync]: core/marker/trait.Sync.html
60-
61-
### If mutable static items that implement `Sync` are safe, why is taking &mut SHARABLE unsafe?
62-
63-
Having multiple aliasing `&mut T`s is never allowed. Due to the nature of
64-
globals, the borrow checker cannot possibly ensure that a static obeys the
65-
borrowing rules, so taking a mutable reference to a static is always unsafe.
66-
67-
## There is no life before or after main (no static ctors/dtors)
68-
69-
Globals can not have a non-constant-expression constructor and cannot have a
70-
destructor at all. This is an opinion of the language. Static constructors are
71-
undesirable because they can slow down program startup. Life before main is
72-
often considered a misfeature, never to be used. Rust helps this along by just
73-
not having the feature.
74-
75-
See [the C++ FQA][fqa] about the "static initialization order fiasco", and
76-
[Eric Lippert's blog][elp] for the challenges in C#, which also has this
77-
feature.
78-
79-
A nice replacement is [lazy_static][lazy_static].
80-
81-
[fqa]: http://yosefk.com/c++fqa/ctors.html#fqa-10.12
82-
[elp]: http://ericlippert.com/2013/02/06/static-constructors-part-one/
83-
[lazy_static]: https://crates.io/crates/lazy_static
84-
85-
## The language does not require a runtime
86-
87-
See the above entry on GC. Requiring a runtime limits the utility of the
88-
language, and makes it undeserving of the title "systems language". All Rust
89-
code should need to run is a stack.
90-
91-
## `match` must be exhaustive
92-
93-
`match` being exhaustive has some useful properties. First, if every
94-
possibility is covered by the `match`, adding further variants to the `enum`
95-
in the future will prompt a compilation failure, rather than runtime panic.
96-
Second, it makes cost explicit. In general, the only safe way to have a
97-
non-exhaustive match would be to panic the thread if nothing is matched, though
98-
it could fall through if the type of the `match` expression is `()`. This sort
99-
of hidden cost and special casing is against the language's philosophy. It's
100-
easy to ignore all unspecified cases by using the `_` wildcard:
101-
102-
```rust,ignore
103-
match val.do_something() {
104-
Cat(a) => { /* ... */ }
105-
_ => { /* ... */ }
106-
}
107-
```
108-
109-
[#3101][iss] is the issue that proposed making this the only behavior, with
110-
rationale and discussion.
111-
112-
[iss]: https://github.com/rust-lang/rust/issues/3101
113-
114-
## No guaranteed tail-call optimization
115-
116-
In general, tail-call optimization is not guaranteed: see [here][tml] for a
117-
detailed explanation with references. There is a [proposed extension][tce] that
118-
would allow tail-call elimination in certain contexts. The compiler is still
119-
free to optimize tail-calls [when it pleases][sco], however.
120-
121-
[tml]: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html
122-
[sco]: http://llvm.org/docs/CodeGenerator.html#sibling-call-optimization
123-
[tce]: https://github.com/rust-lang/rfcs/pull/81
124-
125-
## No constructors
126-
127-
Functions can serve the same purpose as constructors without adding any
128-
language complexity.
129-
130-
## No copy constructors
131-
132-
Types which implement [`Copy`][copy], will do a standard C-like "shallow copy"
133-
with no extra work (similar to "plain old data" in C++). It is impossible to
134-
implement `Copy` types that require custom copy behavior. Instead, in Rust
135-
"copy constructors" are created by implementing the [`Clone`][clone] trait,
136-
and explicitly calling the `clone` method. Making user-defined copy operators
137-
explicit surfaces the underlying complexity, forcing the developer to opt-in
138-
to potentially expensive operations.
139-
140-
[copy]: core/marker/trait.Copy.html
141-
[clone]: core/clone/trait.Clone.html
142-
143-
## No move constructors
144-
145-
Values of all types are moved via `memcpy`. This makes writing generic unsafe
146-
code much simpler since assignment, passing and returning are known to never
147-
have a side effect like unwinding.
148-
149-
# Syntax
150-
151-
## Macros require balanced delimiters
152-
153-
This is to make the language easier to parse for machines. Since the body of a
154-
macro can contain arbitrary tokens, some restriction is needed to allow simple
155-
non-macro-expanding lexers and parsers. This comes in the form of requiring
156-
that all delimiters be balanced.
157-
158-
## `->` for function return type
159-
160-
This is to make the language easier to parse for humans, especially in the face
161-
of higher-order functions. `fn foo<T>(f: fn(i32): i32, fn(T): U): U` is not
162-
particularly easy to read.
163-
164-
## Why is `let` used to introduce variables?
165-
166-
Instead of the term "variable", we use "variable bindings". The
167-
simplest way for creating a binding is by using the `let` syntax.
168-
Other ways include `if let`, `while let`, and `match`. Bindings also
169-
exist in function argument positions.
170-
171-
Bindings always happen in pattern matching positions, and it's also Rust's way
172-
to declare mutability. One can also re-declare mutability of a binding in
173-
pattern matching. This is useful to avoid unnecessary `mut` annotations. An
174-
interesting historical note is that Rust comes, syntactically, most closely
175-
from ML, which also uses `let` to introduce bindings.
176-
177-
See also [a long thread][alt] on renaming `let mut` to `var`.
178-
179-
[alt]: https://mail.mozilla.org/pipermail/rust-dev/2014-January/008319.html
180-
181-
## Why no `--x` or `x++`?
182-
183-
Preincrement and postincrement, while convenient, are also fairly complex. They
184-
require knowledge of evaluation order, and often lead to subtle bugs and
185-
undefined behavior in C and C++. `x = x + 1` or `x += 1` is only slightly
186-
longer, but unambiguous.
3+
This content has moved to [the website](https://www.rust-lang.org/).

0 commit comments

Comments
 (0)