r? @nrc
Since PR #30294 unintentionally fixed issue #30159, it can cause breakage for a different reason than I originally stated in the PR (see #30159, I characterized the issue precisely there).
This commit limits the scope of the breakage to what I originally stated in the PR by "unfixing" the backwards incompatible part of #30159.
I think fixing #30159 has enough potential for breakage to warrant a crater run. If you disagree, I can cancel this PR, leaving it fixed.
r? @steveklabnik
Currently neither the API docs nor the book clearly explain that out-of-bounds array indexing causes a panic. Since this is fairly important and seems to surprise a number of new Rust programmers, I think it's worth adding to both places. (But if you think it would be better to put this info in the API docs only, that's fine too.)
Some specific things I'd like feedback on:
* The new text here talks about panicking, which hasn't been formally introduced at this point in chapter 5 (though it has been mentioned in previous sections too).
* Similarly the `Vec::get` example uses `Option<T>` which hasn't been fully introduced yet. Should we leave out this example?
The landing of #30182, specifically the removal of float `from_str_radix`, allowed the refactoring in the middle commit. While I was at it, I also crossed two other nits off my TODO list.
Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
This commit changes our distribution and in-tree sources to pass the `-C rpath`
flag by default during compiles. This means that from-source builds, including
our release channels, will have this option enabled as well. Motivated
by #29941, this change means that the compiler should be usable as-is on all
platforms just after extraction or installation. This experience is already true
on Windows but on Unixes you still need to set up LD_LIBRARY_PATH or the
equivalent, which can often be unfortunate.
This option was originally turned off by default for Linux distributions who
tend to take care of these sorts of details themselves, so it is expected that
all those builds of Rust will want to pass `--disable-rpath` to the configure
script to preserve that behavior.
Closes#29941
Fixes#29844
I would prefer to
(a) make some performance measurements
(b) use the unification table in a few more places
before committing further, but this is probably good enough for beta.
r? @nikomatsakis
The import has been unnecessarily complicated since ParseFloatError::Invalid is not longer used unqualified.
The pfe_* functions do not need to be public any more since the only other use site, from_str_radix for floats, has been removed.
r? @nagisa
I'm going to need the `ConstVal` -> `ValueRef` translation to start removing trans/consts piece by piece. If you need anything implemented in the translation, feel free to assign an issue to me.
Running `/usr/bin/time -v make` to build rust (using local llvm) shows the maximum memory usage at 715 megabytes on 32-bit x86 (on arm linux it's even less @ 580M).
Reworded according to @brson's [input](https://github.com/rust-lang/rust/pull/30196#issuecomment-162088921).
This fixes a bug in which the visibility of a use declaration defining a name in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace). For example,
```rust
fn f() {}
pub mod bar {}
mod foo {
use f; // This import should not be visible outside `foo`,
pub use bar as f; // but it visible outside of `foo` because of this import.
}
fn main() { foo::f(); }
```
As the example demonstrates, this is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by correcting visibility modifiers.
This PR makes `Mir` `RustcEncodable` and `RustcDecodable` and stores it in crate metadata for inlinable items.
Some other things in here:
- `mir::visit::Visitor` is extended to also visit `Literals`, `Spans` and `DefIds`.
- It also adds `mir::visit::MutVisitor` which allows to mutate the visited `Mir` structure in place.
- Some numbers on how big MIR is in metadata (total metadata size in bytes):
| | w/ MIR | w/o MIR | Rel. Size |
|----------------|-----------:|------------:|:---------:|
| libcore | 17,695,473 | 14,263,377 | 124% |
| liblibc | 411,440 | 404,382 | 102% |
| libcollections | 4,537,975 | 3,526,933 | 129% |
| libserialize | 2,574,769 | 2,060,798 | 125% |
| libsyntax | 15,262,894 | 12,075,574 | 126% |
| librustc | 16,984,537 | 13,692,168 | 124% |
So, adding MIR to metadata makes it about 25% bigger. It could be worse, considering that it still uses the inefficient RBML encoding. Still, the question is whether we should put MIR emission behind a `-Z` flag.
