This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
This PR reverts #29543 and instead implements proper support for "=*m" and "+*m" indirect output operands. This provides a framework on top of which support for plain memory operands ("m", "=m" and "+m") can be implemented.
This also fixes the liveness analysis pass not handling read/write operands correctly.
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
Many of the structs in `str` that are used as part of its methods do not have links to the methods.
This is especially annoying when a Google search drops you into the documentation of the struct, when you really wanted to get to the method of the same name.
This patch adds those links.
This PR for #30299 adds the name of the type where the field is missing.
The span that's used for the error seems correct. What may be confusing is when the initializer with the missing field contains other intializers. These are then included in the span. For example, consider the following listing.
struct A {
a1: i32,
a2: B,
}
struct B {
b1: i32,
b2: i32
}
fn main() {
let x = A {
a2: B {
b1: 1,
b2: 1
},
};
}
It will display the following code snippet along with the message that field `a2` is missing:
let x = A {
a2: B {
b1: 1,
b2: 1
},
};
By adding the name of the type it's clearer where the field is missing.
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.
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.
