Skip to content

Commit

Permalink
Auto merge of #37678 - eddyb:rollup, r=eddyb
Browse files Browse the repository at this point in the history
Rollup of 5 pull requests

- Successful merges: #37402, #37412, #37661, #37664, #37667
- Failed merges:
  • Loading branch information
bors authored Nov 10, 2016
2 parents 0b46947 + 3a5b45a commit b46ce08
Show file tree
Hide file tree
Showing 148 changed files with 1,827 additions and 2,524 deletions.
2 changes: 2 additions & 0 deletions src/doc/book/syntax-index.md
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,7 @@
* `|=` (`var |= expr`): bitwise or & assignment. Overloadable (`BitOrAssign`).
* `||` (`expr || expr`): logical or.
* `_`: "ignored" pattern binding (see [Patterns (Ignoring bindings)]). Also used to make integer-literals readable (see [Reference (Integer literals)]).
* `?` (`expr?`): Error propagation. Returns early when `Err(_)` is encountered, unwraps otherwise. Similar to the [`try!` macro].

## Other Syntax

Expand Down Expand Up @@ -210,6 +211,7 @@
[Functions]: functions.html
[Generics]: generics.html
[Iterators]: iterators.html
[`try!` macro]: error-handling.html#the-try-macro
[Lifetimes]: lifetimes.html
[Loops (`for`)]: loops.html#for
[Loops (`loop`)]: loops.html#loop
Expand Down
8 changes: 6 additions & 2 deletions src/doc/reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -2863,8 +2863,8 @@ assert_eq!(x, y);

### Unary operator expressions

Rust defines the following unary operators. They are all written as prefix operators,
before the expression they apply to.
Rust defines the following unary operators. With the exception of `?`, they are
all written as prefix operators, before the expression they apply to.

* `-`
: Negation. Signed integer types and floating-point types support negation. It
Expand Down Expand Up @@ -2893,6 +2893,10 @@ before the expression they apply to.
If the `&` or `&mut` operators are applied to an rvalue, a
temporary value is created; the lifetime of this temporary value
is defined by [syntactic rules](#temporary-lifetimes).
* `?`
: Propagating errors if applied to `Err(_)` and unwrapping if
applied to `Ok(_)`. Only works on the `Result<T, E>` type,
and written in postfix notation.

### Binary operator expressions

Expand Down
2 changes: 1 addition & 1 deletion src/libpanic_abort/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ pub unsafe extern fn __rust_maybe_catch_panic(f: fn(*mut u8),
// now hopefully.
#[no_mangle]
pub unsafe extern fn __rust_start_panic(_data: usize, _vtable: usize) -> u32 {
return abort();
abort();

#[cfg(unix)]
unsafe fn abort() -> ! {
Expand Down
12 changes: 6 additions & 6 deletions src/librustc/cfg/construct.rs
Original file line number Diff line number Diff line change
Expand Up @@ -33,25 +33,25 @@ struct LoopScope {
}

pub fn construct<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>,
blk: &hir::Block) -> CFG {
body: &hir::Expr) -> CFG {
let mut graph = graph::Graph::new();
let entry = graph.add_node(CFGNodeData::Entry);

// `fn_exit` is target of return exprs, which lies somewhere
// outside input `blk`. (Distinguishing `fn_exit` and `block_exit`
// outside input `body`. (Distinguishing `fn_exit` and `body_exit`
// also resolves chicken-and-egg problem that arises if you try to
// have return exprs jump to `block_exit` during construction.)
// have return exprs jump to `body_exit` during construction.)
let fn_exit = graph.add_node(CFGNodeData::Exit);
let block_exit;
let body_exit;

let mut cfg_builder = CFGBuilder {
graph: graph,
fn_exit: fn_exit,
tcx: tcx,
loop_scopes: Vec::new()
};
block_exit = cfg_builder.block(blk, entry);
cfg_builder.add_contained_edge(block_exit, fn_exit);
body_exit = cfg_builder.expr(body, entry);
cfg_builder.add_contained_edge(body_exit, fn_exit);
let CFGBuilder {graph, ..} = cfg_builder;
CFG {graph: graph,
entry: entry,
Expand Down
4 changes: 2 additions & 2 deletions src/librustc/cfg/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -59,8 +59,8 @@ pub type CFGEdge = graph::Edge<CFGEdgeData>;

impl CFG {
pub fn new<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>,
blk: &hir::Block) -> CFG {
construct::construct(tcx, blk)
body: &hir::Expr) -> CFG {
construct::construct(tcx, body)
}

pub fn node_is_reachable(&self, id: ast::NodeId) -> bool {
Expand Down
12 changes: 6 additions & 6 deletions src/librustc/dep_graph/dep_node.rs
Original file line number Diff line number Diff line change
Expand Up @@ -103,11 +103,11 @@ pub enum DepNode<D: Clone + Debug> {
// nodes. Often we map multiple tables to the same node if there
// is no point in distinguishing them (e.g., both the type and
// predicates for an item wind up in `ItemSignature`).
ImplOrTraitItems(D),
AssociatedItems(D),
ItemSignature(D),
FieldTy(D),
SizedConstraint(D),
ImplOrTraitItemDefIds(D),
AssociatedItemDefIds(D),
InherentImpls(D),

// The set of impls for a given trait. Ultimately, it would be
Expand Down Expand Up @@ -153,10 +153,10 @@ impl<D: Clone + Debug> DepNode<D> {
TransCrateItem,
TypeckItemType,
TypeckItemBody,
ImplOrTraitItems,
AssociatedItems,
ItemSignature,
FieldTy,
ImplOrTraitItemDefIds,
AssociatedItemDefIds,
InherentImpls,
TraitImpls,
ReprHints,
Expand Down Expand Up @@ -219,11 +219,11 @@ impl<D: Clone + Debug> DepNode<D> {
RvalueCheck(ref d) => op(d).map(RvalueCheck),
TransCrateItem(ref d) => op(d).map(TransCrateItem),
TransInlinedItem(ref d) => op(d).map(TransInlinedItem),
ImplOrTraitItems(ref d) => op(d).map(ImplOrTraitItems),
AssociatedItems(ref d) => op(d).map(AssociatedItems),
ItemSignature(ref d) => op(d).map(ItemSignature),
FieldTy(ref d) => op(d).map(FieldTy),
SizedConstraint(ref d) => op(d).map(SizedConstraint),
ImplOrTraitItemDefIds(ref d) => op(d).map(ImplOrTraitItemDefIds),
AssociatedItemDefIds(ref d) => op(d).map(AssociatedItemDefIds),
InherentImpls(ref d) => op(d).map(InherentImpls),
TraitImpls(ref d) => op(d).map(TraitImpls),
TraitItems(ref d) => op(d).map(TraitItems),
Expand Down
114 changes: 0 additions & 114 deletions src/librustc/diagnostics.rs
Original file line number Diff line number Diff line change
Expand Up @@ -672,120 +672,6 @@ extern "C" {
```
"##,

E0269: r##"
A returned value was expected but not all control paths return one.
Erroneous code example:
```compile_fail,E0269
fn abracada_FAIL() -> String {
"this won't work".to_string();
// error: not all control paths return a value
}
```
In the previous code, the function is supposed to return a `String`, however,
the code returns nothing (because of the ';'). Another erroneous code would be:
```compile_fail
fn abracada_FAIL(b: bool) -> u32 {
if b {
0
} else {
"a" // It fails because an `u32` was expected and something else is
// returned.
}
}
```
It is advisable to find out what the unhandled cases are and check for them,
returning an appropriate value or panicking if necessary. Check if you need
to remove a semicolon from the last expression, like in the first erroneous
code example.
"##,

E0270: r##"
Rust lets you define functions which are known to never return, i.e. are
'diverging', by marking its return type as `!`.
For example, the following functions never return:
```no_run
fn foo() -> ! {
loop {}
}
fn bar() -> ! {
foo() // foo() is diverging, so this will diverge too
}
fn baz() -> ! {
panic!(); // this macro internally expands to a call to a diverging function
}
```
Such functions can be used in a place where a value is expected without
returning a value of that type, for instance:
```no_run
fn foo() -> ! {
loop {}
}
let x = 3;
let y = match x {
1 => 1,
2 => 4,
_ => foo() // diverging function called here
};
println!("{}", y)
```
If the third arm of the match block is reached, since `foo()` doesn't ever
return control to the match block, it is fine to use it in a place where an
integer was expected. The `match` block will never finish executing, and any
point where `y` (like the print statement) is needed will not be reached.
However, if we had a diverging function that actually does finish execution:
```ignore
fn foo() -> ! {
loop {break;}
}
```
Then we would have an unknown value for `y` in the following code:
```no_run
fn foo() -> ! {
loop {}
}
let x = 3;
let y = match x {
1 => 1,
2 => 4,
_ => foo()
};
println!("{}", y);
```
In the previous example, the print statement was never reached when the
wildcard match arm was hit, so we were okay with `foo()` not returning an
integer that we could set to `y`. But in this example, `foo()` actually does
return control, so the print statement will be executed with an uninitialized
value.
Obviously we cannot have functions which are allowed to be used in such
positions and yet can return control. So, if you are defining a function that
returns `!`, make sure that there is no way for it to actually finish
executing.
"##,

E0271: r##"
This is because of a type mismatch between the associated type of some
trait (e.g. `T::Bar`, where `T` implements `trait Quux { type Bar; }`)
Expand Down
8 changes: 4 additions & 4 deletions src/librustc/hir/intravisit.rs
Original file line number Diff line number Diff line change
Expand Up @@ -138,7 +138,7 @@ pub trait Visitor<'v> : Sized {
fn visit_where_predicate(&mut self, predicate: &'v WherePredicate) {
walk_where_predicate(self, predicate)
}
fn visit_fn(&mut self, fk: FnKind<'v>, fd: &'v FnDecl, b: &'v Block, s: Span, id: NodeId) {
fn visit_fn(&mut self, fk: FnKind<'v>, fd: &'v FnDecl, b: &'v Expr, s: Span, id: NodeId) {
walk_fn(self, fk, fd, b, s, id)
}
fn visit_trait_item(&mut self, ti: &'v TraitItem) {
Expand Down Expand Up @@ -635,13 +635,13 @@ pub fn walk_fn_kind<'v, V: Visitor<'v>>(visitor: &mut V, function_kind: FnKind<'
pub fn walk_fn<'v, V: Visitor<'v>>(visitor: &mut V,
function_kind: FnKind<'v>,
function_declaration: &'v FnDecl,
function_body: &'v Block,
function_body: &'v Expr,
_span: Span,
id: NodeId) {
visitor.visit_id(id);
walk_fn_decl(visitor, function_declaration);
walk_fn_kind(visitor, function_kind);
visitor.visit_block(function_body)
visitor.visit_expr(function_body)
}

pub fn walk_trait_item<'v, V: Visitor<'v>>(visitor: &mut V, trait_item: &'v TraitItem) {
Expand Down Expand Up @@ -925,7 +925,7 @@ impl<'v> Visitor<'v> for IdRangeComputingVisitor {
/// Computes the id range for a single fn body, ignoring nested items.
pub fn compute_id_range_for_fn_body(fk: FnKind,
decl: &FnDecl,
body: &Block,
body: &Expr,
sp: Span,
id: NodeId)
-> IdRange {
Expand Down
13 changes: 9 additions & 4 deletions src/librustc/hir/lowering.rs
Original file line number Diff line number Diff line change
Expand Up @@ -595,12 +595,13 @@ impl<'a> LoweringContext<'a> {
hir::ItemConst(self.lower_ty(t), self.lower_expr(e))
}
ItemKind::Fn(ref decl, unsafety, constness, abi, ref generics, ref body) => {
let body = self.lower_block(body);
hir::ItemFn(self.lower_fn_decl(decl),
self.lower_unsafety(unsafety),
self.lower_constness(constness),
abi,
self.lower_generics(generics),
self.lower_block(body))
self.expr_block(body, ThinVec::new()))
}
ItemKind::Mod(ref m) => hir::ItemMod(self.lower_mod(m)),
ItemKind::ForeignMod(ref nm) => hir::ItemForeignMod(self.lower_foreign_mod(nm)),
Expand Down Expand Up @@ -665,7 +666,10 @@ impl<'a> LoweringContext<'a> {
}
TraitItemKind::Method(ref sig, ref body) => {
hir::MethodTraitItem(this.lower_method_sig(sig),
body.as_ref().map(|x| this.lower_block(x)))
body.as_ref().map(|x| {
let body = this.lower_block(x);
this.expr_block(body, ThinVec::new())
}))
}
TraitItemKind::Type(ref bounds, ref default) => {
hir::TypeTraitItem(this.lower_bounds(bounds),
Expand All @@ -691,8 +695,9 @@ impl<'a> LoweringContext<'a> {
hir::ImplItemKind::Const(this.lower_ty(ty), this.lower_expr(expr))
}
ImplItemKind::Method(ref sig, ref body) => {
let body = this.lower_block(body);
hir::ImplItemKind::Method(this.lower_method_sig(sig),
this.lower_block(body))
this.expr_block(body, ThinVec::new()))
}
ImplItemKind::Type(ref ty) => hir::ImplItemKind::Type(this.lower_ty(ty)),
ImplItemKind::Macro(..) => panic!("Shouldn't exist any more"),
Expand Down Expand Up @@ -1110,7 +1115,7 @@ impl<'a> LoweringContext<'a> {
self.with_parent_def(e.id, |this| {
hir::ExprClosure(this.lower_capture_clause(capture_clause),
this.lower_fn_decl(decl),
this.lower_block(body),
this.lower_expr(body),
fn_decl_span)
})
}
Expand Down
Loading

0 comments on commit b46ce08

Please sign in to comment.