While booleans are represented as i1 in SSA values, LLVM expects them
to be stored/loaded as i8 values. Using i1 as we do now works, but
kills some optimizations, so we should switch to i8, just like we do
everywhere else.
Fixes#16959.
Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.
Closes#17837
[breaking-change]
While booleans are represented as i1 in SSA values, LLVM expects them
to be stored/loaded as i8 values. Using i1 as we do now works, but
kills some optimizations, so we should switch to i8, just like we do
everywhere else.
Fixes#16959.
This fixes a soundness problem where `Fn` unboxed closures can mutate free variables in the environment.
The following presently builds:
```rust
#![feature(unboxed_closures, overloaded_calls)]
fn main() {
let mut x = 0u;
let _f = |&:| x = 42;
}
```
However, this is equivalent to writing the following, which borrowck rightly rejects:
```rust
struct F<'a> {
x: &'a mut uint
}
impl<'a> Fn<(),()> for F<'a> {
#[rust_call_abi_hack]
fn call(&self, _: ()) {
*self.x = 42; // error: cannot assign to data in a `&` reference
}
}
fn main() {
let mut x = 0u;
let _f = F { x: &mut x };
}
```
This problem is unique to unboxed closures; boxed closures cannot be invoked through an immutable reference and are not subject to it.
This change marks upvars of `Fn` unboxed closures as freely aliasable in mem_categorization, which causes borrowck to reject attempts to mutate or mutably borrow them.
@zwarich pointed out that even with this change, there are remaining soundness issues related to regionck (issue #17403). This region issue affects boxed closures as well.
Closes issue #17780
Apart from making the build system determine the LLDB version, this PR also fixes an issue with enums in LLDB pretty printers. In order for GDB's pretty printers to know for sure if a field of some value is an enum discriminant, I had rustc mark discriminant fields with the `artificial` DWARF tag. This worked out nicely for GDB but it turns out that one can't access artificial fields from LLDB. So I changed the debuginfo representation so that enum discriminants are marked by the special field name `RUST$ENUM$DISR` instead, which works in both cases.
The PR does not activate the LLDB test suite yet.
The old version switched in between examples from the value `5i` to `"Hello"` and back.
Additionally, the code generated by `rustc print.rs --pretty=expanded` is not as verbose anymore.
Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.
Closes#17837
[breaking-change]
LLDB doesn't allow for reading 'artifical' fields (fields that are generated by the compiler). So do not mark, slice fields, enum discriminants, and GcBox value fields as artificial.
This provides a way to pass `&[T]` to functions taking `&U` where `U` is
a `Vec<T>`. This is useful in many cases not covered by the Equiv trait
or methods like `find_with` on TreeMap.
This provides a way to pass `&[T]` to functions taking `&U` where `U` is
a `Vec<T>`. This is useful in many cases not covered by the Equiv trait
or methods like `find_with` on TreeMap.
Currently, the Guide says tuples "are only equivalent if the arity, types, and values are all identical", before presenting an example that uses `==` to compare two tuples whose arity and contained types match. This is misleading, because it implies that `==` can dynamically check whether two tuples have the same arity and contained types, whereas trying to do this would lead to a compiler error.
I tried to avoid destroying the flow of this section, but I'm not sure if I've been successful.
Because my '30 minute intro' was originally a blog post, the tone was a bit too light. It also was written a long time ago, and deserves a bit of a refresher for modern Rust. now that my work on the Guide is wrapping up, I want to give it a quick re-write as well.
This is not yet done, but I'm submitting it for feedback so far. I'd really like some comments on the ownership part in particular, which gets lower level than before, but is not strictly 100% accurate. Trying to strike a balance.
In general, I'm not sure I go into enough detail for those without systems experience, but am afraid of too much detail for those that do.
Rendered view: https://github.com/steveklabnik/rust/blob/intro_redux/src/doc/intro.md
/cc @wycats @nikomatsakis @brson etc
The old version switched in between examples from the value `5i` to `"Hello"`
and back. Additionally, the code generated by `rustc print.rs
--pretty=expanded` is not as verbose anymore.
Adds a high-level discussion of "what collection should you use for what", as well as some general discussion of correct/efficient usage of the capacity, iterator, and entry APIs.
Still building docs to confirm this renders right and the examples are good, but the content can be reviewed now.
For example, this matcher: `fn $name:ident( $($param:ident : $pty:ty),* )` would fail when parsing `fn foo()`, because macro parser wouldn't realize that an ident cannot start with `)`.
This resolves#5902, and at least partially mitigates #9364 and #3232.
[Previously](e5da6a71a6), the `Any` trait was split into a private portion and an (empty) public portion, in order to hide the implementation strategy used for downcasting. However, the [new rules](e9ad12c0ca) for privacy forbid `AnyPrivate` from actually being private.
This patch thus reverts the introduction of `AnyPrivate`.
Although this is unlikely to break any real code, it removes a public trait and is therefore a:
[breaking-change]
