This commit removes the <M: Any + Send> type parameter from Option::expect in
favor of just taking a hard-coded `&str` argument. This allows this function to
move into libcore.
Previous code using strings with `expect` will continue to work, but code using
this implicitly to transmit task failure will need to unwrap manually with a
`match` statement.
[breaking-change]
Closes#14008
This completes the last stage of the renaming of the comparison hierarchy of
traits. This change renames TotalEq to Eq and TotalOrd to Ord.
In the future the new Eq/Ord will be filled out with their appropriate methods,
but for now this change is purely a renaming change.
[breaking-change]
This is part of the ongoing renaming of the equality traits. See #12517 for more
details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord}
or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}.
cc #12517
[breaking-change]
So far the DWARF information for enums was different for regular enums, univariant enums, Option-like enums, etc. Regular enums were encoded as unions of structs, while the other variants were encoded as bare structs. With the changes in this PR all enums are encoded as unions so that debuggers can reconstruct if something originally was a struct, a univariant enum, or an Option-like enum. For the latter case, information about the *Null* variant is encoded into the union field name. This information can then be used by the debugger to print a `None` value actually as `None` instead of `Some(0x0)`.
The changes in this PR should also fix the regression reported in #14385 and #14411, but I want to close these only after I have confirmation from the original reporters that the issues are actually fixed for them.
So far the DWARF information for enums was different
for regular enums, univariant enums, Option-like enums,
etc. Regular enums were encoded as unions of structs,
while the other variants were encoded as bare structs.
With the changes in this PR all enums are encoded as
unions so that debuggers can reconstruct if something
originally was a struct, a univariant enum, or an
Option-like enum. For the latter case, information
about the Null variant is encoded into the union field
name. This information can then be used by the
debugger to print a None value actually as None
instead of Some(0x0).
We can now mark arguments and returns as `nonnull` in LLVM. It's still somewhat limited by the fact that LLVM loses this information after inlining but it might help in certain cases.
It can be easy to accidentally bloat the size of an enum by making one variant
larger than the others. When this happens, it usually goes unnoticed. This
commit adds a lint that can warn when the largest variant in an enum is more
than 3 times larger than the second-largest variant. This requires a little
bit of rejiggering, because size information is only available in trans, but
lint levels are only available in the lint context.
It is allow by default because it's pretty noisy, and isn't really *that*
undesirable.
Closes#10362
The span on a inner doc-comment would point to the next token, e.g. the span for the `a` line points to the `b` line, and the span of `b` points to the `fn`.
```rust
//! a
//! b
fn bar() {}
```
The #[phase(syntax,link)] attribute on `extern crate std` needs to be an
outer attribute so it can pretty-print properly.
Also add `#![no_std]` and `#[feature(phase)]` so compiling the
pretty-printed source will work.
The #[phase(syntax,link)] attribute on `extern crate std` needs to be an
outer attribute so it can pretty-print properly.
Also add `#![no_std]` and `#[feature(phase)]` so compiling the
pretty-printed source will work.
Consider PatEnums constructed with A(..) to be candidates for tuple
struct patterns, not just ones constructed with A(a,b,c). If these
patterns shouldn't be valid tuple struct patterns (as they're equivalent
to _), this needs to be caught before we get to trans.
Fixes#14308.
This commit is part of the ongoing libstd facade efforts (cc #13851). The
compiler now recognizes some language items as "extern { fn foo(...); }" and
will automatically perform the following actions:
1. The foreign function has a pre-defined name.
2. The crate and downstream crates can only be built as rlibs until a crate
defines the lang item itself.
3. The actual lang item has a pre-defined name.
This is essentially nicer compiler support for the hokey
core-depends-on-std-failure scheme today, but it is implemented the same way.
The details are a little more hidden under the covers.
In addition to failure, this commit promotes the eh_personality and
rust_stack_exhausted functions to official lang items. The compiler can generate
calls to these functions, causing linkage errors if they are left undefined. The
checking for these items is not as precise as it could be. Crates compiling with
`-Z no-landing-pads` will not need the eh_personality lang item, and crates
compiling with no split stacks won't need the stack exhausted lang item. For
ease, however, these items are checked for presence in all final outputs of the
compiler.
It is quite easy to define dummy versions of the functions necessary:
#[lang = "stack_exhausted"]
extern fn stack_exhausted() { /* ... */ }
#[lang = "eh_personality"]
extern fn eh_personality() { /* ... */ }
cc #11922, rust_stack_exhausted is now a lang item
cc #13851, libcollections is blocked on eh_personality becoming weak
This slightly adjusts the NullablePointer representation for some enums in the case where the non-nullable variant has a single field (the ptr field) to be just that, the pointer. This is in contrast to the current behaviour where we'd wrap that single pointer in a LLVM struct.
Fixes#11040 & #11303.
