- 14 4月, 2015 6 次提交
-
-
由 Richo Healey 提交于
-
由 Richo Healey 提交于
This allows you to distinguish between an option that defaulted, and an option selected by the user
-
由 Richo Healey 提交于
Optimization is now on by default. Closes #24405
-
由 bors 提交于
r? @steveklabnik Should land this, https://github.com/rust-lang/rust/pull/24270, and https://github.com/rust-lang/rust/pull/24245 before rolling another beta.
-
由 bors 提交于
As pointed out in [RFC issue 1043][rfc] it is quite useful to have the standard I/O types to provide the contract that they are the sole owner of the underlying object they represent. This guarantee enables writing safe interfaces like the `MemoryMap` API sketched out in that issue. [rfc]: https://github.com/rust-lang/rfcs/issues/1043 As constructing objects from these raw handles may end up violating these ownership gurantees, the functions for construction are now marked unsafe. [breaking-change] Closes rust-lang/rfcs#1043
-
由 bors 提交于
The current implementation of using GetFinalPathNameByHandle actually reads all intermediate links instead of just looking at the current link. This commit alters the behavior of the function to use a different API which correctly reads only one level of the soft link. [breaking-change]
-
- 13 4月, 2015 14 次提交
-
-
由 bors 提交于
Make sure the unstable `scoped` modules isn't named the same as the `scoped` function. cc #24334
-
由 bors 提交于
This PR makes `rustc` emit field names for tuple fields in DWARF. Formerly there was no way of directly accessing the fields of a tuple in GDB and LLDB since there is no C/C++ equivalent to this. Now, the debugger sees the name `__{field-index}` for tuple fields. So you can type for example `some_tuple_val.__2` to get the third tuple component. When pretty printers are used (e.g. via `rust-gdb` or `rust-lldb`) these artificial field names will not clutter tuple rendering (which was the main motivation for not doing this in the past). Solves #21948.
-
由 bors 提交于
On linux, certain crashes can cause rust's backtrace generation code to consume huge amounts of memory (multiple gigabytes) when trying to generate a backtrace (e.g. servo/servo#5340). I tracked this down to a bug in libbacktrace's allocation strategy when processing large binaries, and thankfully it's already been fixed upstream. The change which fixes this specific issue is r210256, and is discussed here: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00547.html I assume we'd prefer to update libbacktrace wholesale, rather than cherry-picking individual patches, so this PR updates libbacktrace to the latest code from svn://gcc.gnu.org/svn/gcc/trunk/libbacktrace (r220112). I've copied the upstream code and reapplied the parts of the following commits which touch src/libbacktrace: - cd8f3175 - fcb30a0b I have not reapplied f5765793 or d51047de, as those are both cosmetic cleanups applied to the entire codebase. For this directory, it seems worthwhile diverging as little as possible from upstream, to reduce the effort of future updates. But I can add them as well if preferred.
-
由 bors 提交于
The regex crate keeps its own tables now (rust-lang/regex#41) so we don't need them here. [breaking-change]
-
由 bors 提交于
There are syntax extensions that call `std::rt::begin_unwind` passing it a `usize`. I updated the syntax extension to instead pass `u32`, but for bootstrapping reasons, I needed to create a `#[cfg(stage0)]` version of `std::rt::begin_unwind` and therefore also `panic!`.
-
由 Alex Crichton 提交于
Make sure the unstable `scoped` modules isn't named the same as the `scoped` function. cc #24334
-
由 bors 提交于
Also add docs because not being able to discover these things is the pits. This was lifted from http://blog.jgc.org/2015/04/the-one-line-you-should-add-to-every.html , and solves a problem I've solved myself a *lot* of times, often in massively inferior ways. Super open to documenting it somewhere other than nitty-gritty, which isn't immediately obvious.
-
由 bors 提交于
Right now, if the user requests to increase the vector size via reserve() or push_back() and the request brings the attempted memory above usize::MAX, we panic. With this change there is only a panic if the minimum requested memory that could meet the requirement is above usize::MAX- otherwise it simply requests its largest capacity possible, usize::MAX.
-
由 Chris Wong 提交于
The regex crate keeps its own tables now (rust-lang/regex#41) so we don't need them here. [breaking-change]
-
由 bors 提交于
- Successful merges: #24072, #24233, #24321, #24339, #24341, #24342, #24347 - Failed merges:
-
由 Manish Goregaokar 提交于
Docs meant that ParseIntError is returned though the function returns ParseFloatError.
-
由 Michael Woerister 提交于
-
由 bcoopers 提交于
with "let" when building on stage0. So change the error message to a static const.
-
由 bors 提交于
Also fixed bug calling .note() instead of .help() See #24036
-
- 12 4月, 2015 18 次提交
-
-
由 Manish Goregaokar 提交于
The "static and dynamic dispatch" chapter seems to no longer exist but there is a dead link from the Traits chapter pointing to it. Have changed the link to point to "Trait Objects" which covers static and dynamic dispatch.
-
由 Manish Goregaokar 提交于
Closes #16602
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Also fixed bug calling .note() instead of .help() See #24036
-
由 Igor Strebezhev 提交于
Docs meant that Option is returned though the function returns Result.
-
由 bors 提交于
-
由 bors 提交于
* In `noop_fold_expr`, call `new_span` in these cases: - `ExprMethodCall`'s identifier - `ExprField`'s identifier - `ExprTupField`'s integer Calling `new_span` for `ExprMethodCall`'s identifier is necessary to print an acceptable diagnostic for `write!(&2, "")`. We see this error: ``` <std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt` <std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) ) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` With this change, we also see a macro expansion backtrace leading to the `write!(&2, "")` call site. * After fully expanding a macro, we replace the expansion expression's span with the original span. Call `fld.new_span` to add a backtrace to this span. (Note that I'm call `new_span` after `bt.pop()`, so the macro just expanded isn't on the backtrace.) The motivating example for this change is `println!("{}")`. The format string literal is `concat!($fmt, "arg")` and is inside the libstd macro. We need to see the backtrace to find the `println!` call site. * Add a backtrace to the `format_args!` format expression span. r? alexcrichton Addresses #23459
-
由 Corey Farwell 提交于
-
由 bors 提交于
Fix #23896.
-
由 Michael Alexander 提交于
-
由 Nick Cameron 提交于
-
由 bors 提交于
We provide tools to tell what exact symbols to emit for any fn or static, but don’t quite check if that won’t cause any issues later on. Some of the issues include LLVM mangling our names again and our names pointing to wrong locations, us generating dumb foreign call wrappers, linker errors, extern functions resolving to different symbols altogether (`extern {fn fail();} fail();` in some cases calling `fail1()`), etc. Before the commit we had a function called `note_unique_llvm_symbol`, so it is clear somebody was aware of the issue at some point, but the function was barely used, mostly in irrelevant locations. Along with working on it I took liberty to start refactoring trans/base into a few smaller modules. The refactoring is incomplete and I hope I will find some motivation to carry on with it. This is possibly a [breaking-change] because it makes dumbly written code properly invalid. This fixes all those issues about incorrect use of #[no_mangle] being not reported/misreported/ICEd by the compiler. NB. This PR does not attempt to tackle the parallel codegen issue that was mentioned in https://github.com/rust-lang/rust/pull/22811, but I believe it should be very straightforward in a follow up PR by modifying `trans::declare::get_defined_value` to look at all the contexts. cc @alexcrichton @huonw @nrc because you commented on the original RFC issue. EDIT: wow, this became much bigger than I initially intended.
-
由 Ryan Prichard 提交于
It was added in 2011-08-05 and reduced to a no-op ten days later.
-
由 Ryan Prichard 提交于
-
由 Ryan Prichard 提交于
-
由 Ryan Prichard 提交于
-
由 Ryan Prichard 提交于
* In noop_fold_expr, call new_span in these cases: - ExprMethodCall's identifier - ExprField's identifier - ExprTupField's integer Calling new_span for ExprMethodCall's identifier is necessary to print an acceptable diagnostic for write!(&2, ""). We see this error: <std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt` <std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) ) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With this change, we also see a macro expansion backtrace leading to the write!(&2, "") call site. * After fully expanding a macro, we replace the expansion expression's span with the original span. Call fld.new_span to add a backtrace to this span. (Note that I'm call new_span after bt.pop(), so the macro just expanded isn't on the backtrace.) The motivating example for this change is println!("{}"). The format string literal is concat!($fmt, "arg") and is inside the libstd macro. We need to see the backtrace to find the println! call site. * Add a backtrace to the format_args! format expression span. Addresses #23459
-
由 bors 提交于
-
- 11 4月, 2015 2 次提交
-
-
由 Manish Goregaokar 提交于
-
由 bors 提交于
This fixes the bug described in issue #23150. This affected formatting any floating point number into a string in a formatting pattern that: a) required rounding up, and b) required an extra digit on the front. So `format!("{:.0}", 9.9)` would fail, but `format!("{:.0}", 8.9)` would succeed. This was due to a negative integer being cast to a `usize` resulting in an 'arithmetic operation overflowed' panic. The fix was to change the order of operations so that the number is zero before casting.
-