Auto merge of #24251 - alexcrichton:unsafe-from-raw-fd, r=aturon
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.
Auto merge of #24198 - alexcrichton:windows-readlink, r=aturon
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.
Auto merge of #24351 - michaelwoerister:named-tuple-fields, r=alexcrichton
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).
Auto merge of #24344 - gfxmonk:update-libbacktrace, r=pnkfelix
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:
I have not reapplied f5765793b650e45e8c9bc89dfc7a4dc628123cb7 or d51047ded072b412ec18a6f78c1fb80835a477f5, 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.
Auto merge of #24323 - rprichard:panic-line-type, r=alexcrichton
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!`.
Auto merge of #24315 - richo:make-debug-helper, r=pnkfelix
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.
Auto merge of #23849 - bcoopers:master, r=pnkfelix
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.
Auto merge of #24003 - rprichard:span-fixes, r=huonw
* 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.
Auto merge of #23011 - nagisa:the-war-of-symbol-and-symbol, r=pnkfelix
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 [Fri, 3 Apr 2015 08:27:04 +0000 (01:27 -0700)]
Propagate macro backtraces more often, improve formatting diagnostics
* 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.
Auto merge of #24269 - benashford:formatting-fix, r=alexcrichton
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.
Rollup merge of #24291 - xamgore:patch-1, r=steveklabnik
From [here](http://doc.rust-lang.org/nightly/std/primitive.i8.html):
> `fn rotate_right(self, n: u32) -> i8`
> Shifts the bits to the right by a specified __amount amount__, n, wrapping the truncated bits to the beginning of the resulting integer.
Rollup merge of #24279 - libfud:vec_insertion_docs, r=steveklabnik
...to be less confusing. Since 0 is the smallest number possible for usize, it doesn't make sense to mention it if it's already included, and it should be more clear that the length of the vector is a valid index with the new wording.
Rollup merge of #24245 - nikomatsakis:issue-24241-coherence-failure, r=pnkfelix
Don't use skolemized parameters but rather fresh variables in coherence. Skolemized parameters wind up preventing unification. Surprised we had no test for this! Fixes #24241.
Rollup merge of #24239 - steveklabnik:editing_pass, r=steveklabnik
Now that the new TOC has landed, I've started doing an editing pass to get the old content into the right shape. I felt this introduction was significant enough to send as its own PR, though, as it's the introduction.
It's possible that we may just want to replace 'the intro' with this directly, but this PR doesn't do that.
Rollup merge of #24269 - benashford:formatting-fix, r=alexcrichton
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.
Auto merge of #24155 - chris-chambers:stmt_macros, r=sfackler
Statement macros are now treated somewhat like item macros, in that a statement macro can now expand into a series of statements, rather than just a single statement.
This allows statement macros to be nested inside other kinds of macros and expand properly, where previously the expansion would only work when no nesting was present.
This changes the interface of the MacResult trait. make_stmt has become make_stmts and now returns a vector, rather than a single item. Plugin writers who were implementing MacResult will have breakage, as well as anyone using MacEager::stmt.
See:
- `src/libsyntax/ext/base.rs`
This also causes a minor difference in behavior to the diagnostics produced by certain malformed macros.
Auto merge of #24270 - pnkfelix:use-disr-val-for-derive-ord, r=brson
Use `discriminant_value` intrinsic for `derive(PartialOrd)`
[breaking-change]
This is a [breaking-change] because it can change the result of comparison operators when enum discriminants have been explicitly assigned. Notably in a case like:
```rust
#[derive(PartialOrd)]
enum E { A = 2, B = 1}
```
Under the old deriving, `A < B` held, because `A` came before `B` in the order of declaration. But now we use the ordering according to the provided values, and thus `A > B`. (However, this change is very unlikely to break much, if any, code, since the orderings themselves should all remain well-defined, total, etc.)
Auto merge of #24177 - alexcrichton:rustdoc, r=aturon
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).
I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
Dominick Allen [Fri, 10 Apr 2015 15:33:21 +0000 (11:33 -0400)]
Changed the wording of the documentation for the insert method for Vec to be less confusing. Since 0 is the smallest number possible for usize, it doesn't make sense to mention it if it's already included, and it should be more clear that the length of the vector is a valid index with the new wording.
projects / rust.git / log