- 10 10月, 2014 13 次提交
-
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
This require a bit of finesse to work around the changes with libunicode, but nothing too major!
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
This commit repurposes most statics as constants in the standard library itself, with the exception of TLS keys which precisely have their own memory location as an implementation detail. This commit also rewrites the bitflags syntax to use `const` instead of `static`. All invocations will need to replace the word `static` with `const` when declaring flags. Due to the modification of the `bitflags!` syntax, this is a: [breaking-change]
-
由 Alex Crichton 提交于
This leaves the ziggurat tables as `pub static` as they're likely too large to want to go into the metadata anyway.
-
由 Alex Crichton 提交于
This crate is largely just one giant header file, so there's no need for any of these values to actually have a memory location, they're all just basically a regular #define.
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
The tables in libunicode are far too large to want to be inlined into any other program, so these tables are all going to remain `static`. For them to be legal, they cannot reference one another by value, but instead use references now. This commit also modifies the src/etc/unicode.py script to generate the right tables.
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
This change is an implementation of [RFC 69][rfc] which adds a third kind of global to the language, `const`. This global is most similar to what the old `static` was, and if you're unsure about what to use then you should use a `const`. The semantics of these three kinds of globals are: * A `const` does not represent a memory location, but only a value. Constants are translated as rvalues, which means that their values are directly inlined at usage location (similar to a #define in C/C++). Constant values are, well, constant, and can not be modified. Any "modification" is actually a modification to a local value on the stack rather than the actual constant itself. Almost all values are allowed inside constants, whether they have interior mutability or not. There are a few minor restrictions listed in the RFC, but they should in general not come up too often. * A `static` now always represents a memory location (unconditionally). Any references to the same `static` are actually a reference to the same memory location. Only values whose types ascribe to `Sync` are allowed in a `static`. This restriction is in place because many threads may access a `static` concurrently. Lifting this restriction (and allowing unsafe access) is a future extension not implemented at this time. * A `static mut` continues to always represent a memory location. All references to a `static mut` continue to be `unsafe`. This is a large breaking change, and many programs will need to be updated accordingly. A summary of the breaking changes is: * Statics may no longer be used in patterns. Statics now always represent a memory location, which can sometimes be modified. To fix code, repurpose the matched-on-`static` to a `const`. static FOO: uint = 4; match n { FOO => { /* ... */ } _ => { /* ... */ } } change this code to: const FOO: uint = 4; match n { FOO => { /* ... */ } _ => { /* ... */ } } * Statics may no longer refer to other statics by value. Due to statics being able to change at runtime, allowing them to reference one another could possibly lead to confusing semantics. If you are in this situation, use a constant initializer instead. Note, however, that statics may reference other statics by address, however. * Statics may no longer be used in constant expressions, such as array lengths. This is due to the same restrictions as listed above. Use a `const` instead. [breaking-change] [rfc]: https://github.com/rust-lang/rfcs/pull/246
-
由 Alex Crichton 提交于
Remove a bunch of two-space tabs
-
- 09 10月, 2014 13 次提交
-
-
由 bors 提交于
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.
-
由 bors 提交于
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]
-
由 Björn Steinbrink 提交于
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.
-
由 bors 提交于
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
-
由 bors 提交于
A fix for the issues mentioned in https://github.com/rust-lang/rust/issues/16413
-
由 bors 提交于
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.
-
由 bors 提交于
I rearranged one sentence in the macros guide to make it less awkward.
-
由 bors 提交于
-
由 Steve Klabnik 提交于
Fixes #16413
-
由 Steve Klabnik 提交于
this is true as of https://github.com/rust-lang/rust/pull/15319
-
由 Julian Orth 提交于
-
由 bors 提交于
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.
-
由 Daniel Micay 提交于
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]
-
- 08 10月, 2014 14 次提交
-
-
由 bors 提交于
Closes #17862
-
由 bors 提交于
Markdown tables require a header, and we don't want one. Fixes #17528
-
由 Michael Woerister 提交于
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.
-
由 bors 提交于
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.
-
由 Daniel Micay 提交于
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.
-
由 Michael Woerister 提交于
-
由 bors 提交于
Closes #17751
-
由 bors 提交于
-
由 John Gallagher 提交于
-
由 John Gallagher 提交于
-
由 John Gallagher 提交于
-
由 Joseph Crail 提交于
-
由 John Gallagher 提交于
-
由 bors 提交于
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.
-