2014-02-10 15:36:31 +01:00
|
|
|
// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
|
2012-12-03 16:48:01 -08:00
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2014-03-21 18:05:05 -07:00
|
|
|
#![allow(non_camel_case_types)]
|
2013-01-07 14:16:52 -08:00
|
|
|
|
2012-09-04 11:54:36 -07:00
|
|
|
use back::abi;
|
2014-07-07 17:58:01 -07:00
|
|
|
use llvm;
|
|
|
|
use llvm::{ValueRef};
|
2014-11-15 20:30:33 -05:00
|
|
|
use trans::base::*;
|
|
|
|
use trans::base;
|
|
|
|
use trans::build::*;
|
|
|
|
use trans::cleanup;
|
|
|
|
use trans::cleanup::CleanupMethods;
|
|
|
|
use trans::common::*;
|
|
|
|
use trans::datum::*;
|
|
|
|
use trans::expr::{Dest, Ignore, SaveIn};
|
|
|
|
use trans::expr;
|
|
|
|
use trans::glue;
|
|
|
|
use trans::machine;
|
|
|
|
use trans::machine::{nonzero_llsize_of, llsize_of_alloc};
|
|
|
|
use trans::type_::Type;
|
|
|
|
use trans::type_of;
|
2014-09-13 21:09:25 +03:00
|
|
|
use middle::ty::{mod, Ty};
|
2014-06-21 03:39:03 -07:00
|
|
|
use util::ppaux::ty_to_string;
|
2012-12-13 13:05:22 -08:00
|
|
|
|
|
|
|
use syntax::ast;
|
2014-01-10 14:02:36 -08:00
|
|
|
use syntax::parse::token::InternedString;
|
2011-08-22 11:48:00 -07:00
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
fn get_len(bcx: Block, vptr: ValueRef) -> ValueRef {
|
2014-04-25 15:14:52 +12:00
|
|
|
let _icx = push_ctxt("tvec::get_lenl");
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
Load(bcx, expr::get_len(bcx, vptr))
|
2011-08-25 10:18:02 +02:00
|
|
|
}
|
2014-01-07 08:54:58 -08:00
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
fn get_dataptr(bcx: Block, vptr: ValueRef) -> ValueRef {
|
2013-06-17 16:23:24 +12:00
|
|
|
let _icx = push_ctxt("tvec::get_dataptr");
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
Load(bcx, expr::get_dataptr(bcx, vptr))
|
2011-08-25 10:18:02 +02:00
|
|
|
}
|
2011-08-22 11:48:00 -07:00
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn pointer_add_byte(bcx: Block, ptr: ValueRef, bytes: ValueRef) -> ValueRef {
|
2013-10-16 12:04:51 -04:00
|
|
|
let _icx = push_ctxt("tvec::pointer_add_byte");
|
2011-08-25 10:18:02 +02:00
|
|
|
let old_ty = val_ty(ptr);
|
2014-03-15 22:29:34 +02:00
|
|
|
let bptr = PointerCast(bcx, ptr, Type::i8p(bcx.ccx()));
|
2014-11-17 21:39:01 +13:00
|
|
|
return PointerCast(bcx, InBoundsGEP(bcx, bptr, &[bytes]), old_ty);
|
2011-08-25 10:18:02 +02:00
|
|
|
}
|
2011-08-22 11:48:00 -07:00
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn make_drop_glue_unboxed<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
vptr: ValueRef,
|
2014-09-29 22:11:30 +03:00
|
|
|
unit_ty: Ty<'tcx>,
|
2014-09-06 19:13:04 +03:00
|
|
|
should_deallocate: bool)
|
|
|
|
-> Block<'blk, 'tcx> {
|
2014-04-25 15:14:52 +12:00
|
|
|
let not_null = IsNotNull(bcx, vptr);
|
|
|
|
with_cond(bcx, not_null, |bcx| {
|
2014-09-05 03:39:15 -04:00
|
|
|
let ccx = bcx.ccx();
|
2014-04-25 15:14:52 +12:00
|
|
|
let tcx = bcx.tcx();
|
|
|
|
let _icx = push_ctxt("tvec::make_drop_glue_unboxed");
|
|
|
|
|
2014-04-06 13:54:41 +03:00
|
|
|
let dataptr = get_dataptr(bcx, vptr);
|
2014-04-25 15:14:52 +12:00
|
|
|
let bcx = if ty::type_needs_drop(tcx, unit_ty) {
|
2014-08-29 18:37:45 +12:00
|
|
|
let len = get_len(bcx, vptr);
|
debuginfo: Make sure that all calls to drop glue are associated with debug locations.
This commit makes rustc emit debug locations for all call
and invoke statements in LLVM IR, if they are contained
within a function that debuginfo is enabled for. This is
important because LLVM does not handle the case where a
function body containing debuginfo is inlined into another
function with debuginfo, but the inlined call statement
does not have a debug location. In this case, LLVM will
not know where (in terms of source code coordinates) the
function was inlined to and we end up with some statements
still linked to the source locations in there original,
non-inlined function without any indication that they are
indeed an inline-copy. Later, when generating DWARF from
the IR, LLVM will interpret this as corrupt IR and abort.
Unfortunately, the undesirable case described above can
still occur when using LTO. If there is a crate compiled
without debuginfo calling into a crate compiled with
debuginfo, we again end up with the conditions triggering
the error. This is why some LTO tests still fail with the
dreaded assertion, if the standard library was built with
debuginfo enabled.
That is, `RUSTFLAGS_STAGE2=-g make rustc-stage2` will
succeed but `RUSTFLAGS_STAGE2=-g make check` will still
fail after this commit has been merged. This is a problem
that has to be dealt with separately.
Fixes #17201
Fixes #15816
Fixes #15156
2014-09-24 08:49:38 +02:00
|
|
|
iter_vec_raw(bcx, dataptr, unit_ty, len, |bb, vv, tt| glue::drop_ty(bb, vv, tt, None))
|
2014-04-25 15:14:52 +12:00
|
|
|
} else {
|
|
|
|
bcx
|
|
|
|
};
|
|
|
|
|
2014-08-29 18:37:45 +12:00
|
|
|
if should_deallocate {
|
2014-09-08 19:27:06 -04:00
|
|
|
let llty = type_of::type_of(ccx, unit_ty);
|
|
|
|
let unit_size = llsize_of_alloc(ccx, llty);
|
|
|
|
if unit_size != 0 {
|
|
|
|
let len = get_len(bcx, vptr);
|
2014-10-14 23:36:11 +03:00
|
|
|
let not_empty = ICmp(bcx, llvm::IntNE, len, C_uint(ccx, 0u));
|
2014-09-08 19:27:06 -04:00
|
|
|
with_cond(bcx, not_empty, |bcx| {
|
2014-10-14 23:36:11 +03:00
|
|
|
let llalign = C_uint(ccx, machine::llalign_of_min(ccx, llty));
|
|
|
|
let size = Mul(bcx, C_uint(ccx, unit_size), len);
|
2014-09-08 19:27:06 -04:00
|
|
|
glue::trans_exchange_free_dyn(bcx, dataptr, size, llalign)
|
|
|
|
})
|
|
|
|
} else {
|
|
|
|
bcx
|
|
|
|
}
|
2014-08-29 18:37:45 +12:00
|
|
|
} else {
|
|
|
|
bcx
|
|
|
|
}
|
2014-04-25 15:14:52 +12:00
|
|
|
})
|
2011-08-22 13:30:53 -07:00
|
|
|
}
|
|
|
|
|
2014-09-29 22:11:30 +03:00
|
|
|
pub struct VecTypes<'tcx> {
|
|
|
|
pub unit_ty: Ty<'tcx>,
|
2014-03-28 10:05:27 -07:00
|
|
|
pub llunit_ty: Type,
|
|
|
|
pub llunit_size: ValueRef,
|
|
|
|
pub llunit_alloc_size: u64
|
2012-08-03 18:48:17 -07:00
|
|
|
}
|
|
|
|
|
2014-09-29 22:11:30 +03:00
|
|
|
impl<'tcx> VecTypes<'tcx> {
|
|
|
|
pub fn to_string<'a>(&self, ccx: &CrateContext<'a, 'tcx>) -> String {
|
2014-05-28 09:24:28 -07:00
|
|
|
format!("VecTypes {{unit_ty={}, llunit_ty={}, \
|
|
|
|
llunit_size={}, llunit_alloc_size={}}}",
|
2014-06-21 03:39:03 -07:00
|
|
|
ty_to_string(ccx.tcx(), self.unit_ty),
|
2014-09-05 09:18:53 -07:00
|
|
|
ccx.tn().type_to_string(self.llunit_ty),
|
|
|
|
ccx.tn().val_to_string(self.llunit_size),
|
2014-05-28 09:24:28 -07:00
|
|
|
self.llunit_alloc_size)
|
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn trans_fixed_vstore<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
expr: &ast::Expr,
|
|
|
|
dest: expr::Dest)
|
|
|
|
-> Block<'blk, 'tcx> {
|
2012-08-28 15:54:45 -07:00
|
|
|
//!
|
|
|
|
//
|
2012-10-10 00:28:04 -04:00
|
|
|
// [...] allocates a fixed-size array and moves it around "by value".
|
2012-08-28 15:54:45 -07:00
|
|
|
// In this case, it means that the caller has already given us a location
|
|
|
|
// to store the array of the suitable size, so all we have to do is
|
|
|
|
// generate the content.
|
|
|
|
|
2014-10-15 02:25:34 -04:00
|
|
|
debug!("trans_fixed_vstore(expr={}, dest={})",
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
bcx.expr_to_string(expr), dest.to_string(bcx.ccx()));
|
2012-08-28 15:54:45 -07:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
let vt = vec_types_from_expr(bcx, expr);
|
2012-08-28 15:54:45 -07:00
|
|
|
|
|
|
|
return match dest {
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
Ignore => write_content(bcx, &vt, expr, expr, dest),
|
2012-08-28 15:54:45 -07:00
|
|
|
SaveIn(lldest) => {
|
|
|
|
// lldest will have type *[T x N], but we want the type *T,
|
|
|
|
// so use GEP to convert:
|
2014-11-17 21:39:01 +13:00
|
|
|
let lldest = GEPi(bcx, lldest, &[0, 0]);
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
write_content(bcx, &vt, expr, expr, SaveIn(lldest))
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn trans_slice_vec<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
slice_expr: &ast::Expr,
|
|
|
|
content_expr: &ast::Expr)
|
|
|
|
-> DatumBlock<'blk, 'tcx, Expr> {
|
2014-01-15 14:39:08 -05:00
|
|
|
/*!
|
|
|
|
* &[...] allocates memory on the stack and writes the values into it,
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
* returning the vector (the caller must make the reference). "..." is
|
|
|
|
* similar except that the memory can be statically allocated and we return
|
|
|
|
* a reference (strings are always by-ref).
|
2014-01-15 14:39:08 -05:00
|
|
|
*/
|
|
|
|
|
|
|
|
let fcx = bcx.fcx;
|
|
|
|
let ccx = fcx.ccx;
|
|
|
|
let mut bcx = bcx;
|
2012-08-03 18:48:17 -07:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
debug!("trans_slice_vec(slice_expr={})",
|
|
|
|
bcx.expr_to_string(slice_expr));
|
|
|
|
|
|
|
|
let vec_ty = node_id_type(bcx, slice_expr.id);
|
2012-08-28 15:54:45 -07:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
// Handle the "..." case (returns a slice since strings are always unsized):
|
2012-08-28 15:54:45 -07:00
|
|
|
match content_expr.node {
|
2014-09-07 20:09:06 +03:00
|
|
|
ast::ExprLit(ref lit) => {
|
2014-01-03 15:08:48 -08:00
|
|
|
match lit.node {
|
2014-01-21 10:08:10 -08:00
|
|
|
ast::LitStr(ref s, _) => {
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
let scratch = rvalue_scratch_datum(bcx, vec_ty, "");
|
|
|
|
bcx = trans_lit_str(bcx,
|
|
|
|
content_expr,
|
|
|
|
s.clone(),
|
|
|
|
SaveIn(scratch.val));
|
|
|
|
return DatumBlock::new(bcx, scratch.to_expr_datum());
|
2014-01-03 15:08:48 -08:00
|
|
|
}
|
|
|
|
_ => {}
|
|
|
|
}
|
2011-09-27 10:50:18 +02:00
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
_ => {}
|
2011-09-27 10:50:18 +02:00
|
|
|
}
|
2012-04-19 15:42:02 -07:00
|
|
|
|
2012-08-28 15:54:45 -07:00
|
|
|
// Handle the &[...] case:
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
let vt = vec_types_from_expr(bcx, content_expr);
|
2012-08-28 15:54:45 -07:00
|
|
|
let count = elements_required(bcx, content_expr);
|
2014-10-15 02:25:34 -04:00
|
|
|
debug!(" vt={}, count={}", vt.to_string(ccx), count);
|
2012-08-28 15:54:45 -07:00
|
|
|
let llcount = C_uint(ccx, count);
|
2014-04-25 15:14:52 +12:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
let fixed_ty = ty::mk_vec(bcx.tcx(),
|
|
|
|
vt.unit_ty,
|
|
|
|
Some(count));
|
|
|
|
let llfixed_ty = type_of::type_of(bcx.ccx(), fixed_ty).ptr_to();
|
|
|
|
|
2014-04-25 15:14:52 +12:00
|
|
|
let llfixed = if count == 0 {
|
2014-07-03 22:24:33 -07:00
|
|
|
// Just create a zero-sized alloca to preserve
|
|
|
|
// the non-null invariant of the inner slice ptr
|
2014-08-06 11:59:40 +02:00
|
|
|
let llfixed = base::arrayalloca(bcx, vt.llunit_ty, llcount);
|
|
|
|
BitCast(bcx, llfixed, llfixed_ty)
|
2014-01-15 14:39:08 -05:00
|
|
|
} else {
|
|
|
|
// Make a fixed-length backing array and allocate it on the stack.
|
2014-04-25 15:14:52 +12:00
|
|
|
let llfixed = base::arrayalloca(bcx, vt.llunit_ty, llcount);
|
2014-01-15 14:39:08 -05:00
|
|
|
|
|
|
|
// Arrange for the backing array to be cleaned up.
|
|
|
|
let llfixed_casted = BitCast(bcx, llfixed, llfixed_ty);
|
|
|
|
let cleanup_scope = cleanup::temporary_scope(bcx.tcx(), content_expr.id);
|
Emit LLVM lifetime intrinsics to improve stack usage and codegen in general
Lifetime intrinsics help to reduce stack usage, because LLVM can apply
stack coloring to reuse the stack slots of dead allocas for new ones.
For example these functions now both use the same amount of stack, while
previous `bar()` used five times as much as `foo()`:
````rust
fn foo() {
println("{}", 5);
}
fn bar() {
println("{}", 5);
println("{}", 5);
println("{}", 5);
println("{}", 5);
println("{}", 5);
}
````
On top of that, LLVM can also optimize out certain operations when it
knows that memory is dead after a certain point. For example, it can
sometimes remove the zeroing used to cancel the drop glue. This is
possible when the glue drop itself was already removed because the
zeroing dominated the drop glue call. For example in:
````rust
pub fn bar(x: (Box<int>, int)) -> (Box<int>, int) {
x
}
````
With optimizations, this currently results in:
````llvm
define void @_ZN3bar20h330fa42547df8179niaE({ i64*, i64 }* noalias nocapture nonnull sret, { i64*, i64 }* noalias nocapture nonnull) unnamed_addr #0 {
"_ZN29_$LP$Box$LT$int$GT$$C$int$RP$39glue_drop.$x22glue_drop$x22$LP$1347$RP$17h88cf42702e5a322aE.exit":
%2 = bitcast { i64*, i64 }* %1 to i8*
%3 = bitcast { i64*, i64 }* %0 to i8*
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 8, i1 false)
tail call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 16, i32 8, i1 false)
ret void
}
````
But with lifetime intrinsics we get:
````llvm
define void @_ZN3bar20h330fa42547df8179niaE({ i64*, i64 }* noalias nocapture nonnull sret, { i64*, i64 }* noalias nocapture nonnull) unnamed_addr #0 {
"_ZN29_$LP$Box$LT$int$GT$$C$int$RP$39glue_drop.$x22glue_drop$x22$LP$1347$RP$17h88cf42702e5a322aE.exit":
%2 = bitcast { i64*, i64 }* %1 to i8*
%3 = bitcast { i64*, i64 }* %0 to i8*
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 8, i1 false)
tail call void @llvm.lifetime.end(i64 16, i8* %2)
ret void
}
````
Fixes #15665
2014-05-01 19:32:07 +02:00
|
|
|
fcx.schedule_lifetime_end(cleanup_scope, llfixed_casted);
|
2014-01-15 14:39:08 -05:00
|
|
|
fcx.schedule_drop_mem(cleanup_scope, llfixed_casted, fixed_ty);
|
|
|
|
|
|
|
|
// Generate the content into the backing array.
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
bcx = write_content(bcx, &vt, slice_expr,
|
2012-08-28 15:54:45 -07:00
|
|
|
content_expr, SaveIn(llfixed));
|
2014-04-25 15:14:52 +12:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
llfixed_casted
|
2014-04-25 15:14:52 +12:00
|
|
|
};
|
2012-08-28 15:54:45 -07:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
immediate_rvalue_bcx(bcx, llfixed, vec_ty).to_expr_datumblock()
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn trans_lit_str<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
lit_expr: &ast::Expr,
|
|
|
|
str_lit: InternedString,
|
|
|
|
dest: Dest)
|
|
|
|
-> Block<'blk, 'tcx> {
|
2014-01-15 14:39:08 -05:00
|
|
|
/*!
|
|
|
|
* Literal strings translate to slices into static memory. This is
|
2014-04-25 15:14:52 +12:00
|
|
|
* different from trans_slice_vstore() above because it doesn't need to copy
|
2014-01-15 14:39:08 -05:00
|
|
|
* the content anywhere.
|
|
|
|
*/
|
2012-08-28 15:54:45 -07:00
|
|
|
|
2013-10-21 13:08:31 -07:00
|
|
|
debug!("trans_lit_str(lit_expr={}, dest={})",
|
2014-06-21 03:39:03 -07:00
|
|
|
bcx.expr_to_string(lit_expr),
|
|
|
|
dest.to_string(bcx.ccx()));
|
2012-08-28 15:54:45 -07:00
|
|
|
|
|
|
|
match dest {
|
|
|
|
Ignore => bcx,
|
|
|
|
SaveIn(lldest) => {
|
2013-01-10 21:23:07 -08:00
|
|
|
unsafe {
|
2014-01-10 14:02:36 -08:00
|
|
|
let bytes = str_lit.get().len();
|
2013-01-10 21:23:07 -08:00
|
|
|
let llbytes = C_uint(bcx.ccx(), bytes);
|
2014-04-03 16:26:08 -04:00
|
|
|
let llcstr = C_cstr(bcx.ccx(), str_lit, false);
|
2014-03-15 22:29:34 +02:00
|
|
|
let llcstr = llvm::LLVMConstPointerCast(llcstr, Type::i8p(bcx.ccx()).to_ref());
|
2014-11-10 18:14:31 +01:00
|
|
|
Store(bcx, llcstr, GEPi(bcx, lldest, &[0u, abi::FAT_PTR_ADDR]));
|
|
|
|
Store(bcx, llbytes, GEPi(bcx, lldest, &[0u, abi::FAT_PTR_EXTRA]));
|
2013-01-10 21:23:07 -08:00
|
|
|
bcx
|
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn write_content<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
2014-09-29 22:11:30 +03:00
|
|
|
vt: &VecTypes<'tcx>,
|
2014-09-06 19:13:04 +03:00
|
|
|
vstore_expr: &ast::Expr,
|
|
|
|
content_expr: &ast::Expr,
|
|
|
|
dest: Dest)
|
|
|
|
-> Block<'blk, 'tcx> {
|
2013-06-17 16:23:24 +12:00
|
|
|
let _icx = push_ctxt("tvec::write_content");
|
2014-01-15 14:39:08 -05:00
|
|
|
let fcx = bcx.fcx;
|
2012-08-28 15:54:45 -07:00
|
|
|
let mut bcx = bcx;
|
|
|
|
|
2014-10-15 02:25:34 -04:00
|
|
|
debug!("write_content(vt={}, dest={}, vstore_expr={})",
|
2014-06-21 03:39:03 -07:00
|
|
|
vt.to_string(bcx.ccx()),
|
|
|
|
dest.to_string(bcx.ccx()),
|
|
|
|
bcx.expr_to_string(vstore_expr));
|
2012-08-28 15:54:45 -07:00
|
|
|
|
2013-03-20 01:17:42 -04:00
|
|
|
match content_expr.node {
|
2014-09-07 20:09:06 +03:00
|
|
|
ast::ExprLit(ref lit) => {
|
2014-01-03 15:08:48 -08:00
|
|
|
match lit.node {
|
2014-01-10 14:02:36 -08:00
|
|
|
ast::LitStr(ref s, _) => {
|
2014-01-03 15:08:48 -08:00
|
|
|
match dest {
|
2014-01-10 14:02:36 -08:00
|
|
|
Ignore => return bcx,
|
2014-01-03 15:08:48 -08:00
|
|
|
SaveIn(lldest) => {
|
2014-01-10 14:02:36 -08:00
|
|
|
let bytes = s.get().len();
|
2014-01-03 15:08:48 -08:00
|
|
|
let llbytes = C_uint(bcx.ccx(), bytes);
|
2014-04-03 16:26:08 -04:00
|
|
|
let llcstr = C_cstr(bcx.ccx(), (*s).clone(), false);
|
2014-01-03 15:08:48 -08:00
|
|
|
base::call_memcpy(bcx,
|
|
|
|
lldest,
|
|
|
|
llcstr,
|
|
|
|
llbytes,
|
|
|
|
1);
|
|
|
|
return bcx;
|
|
|
|
}
|
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
2014-01-03 15:08:48 -08:00
|
|
|
_ => {
|
|
|
|
bcx.tcx().sess.span_bug(content_expr.span,
|
2014-02-06 10:38:08 +01:00
|
|
|
"unexpected evec content");
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
2012-08-03 18:48:17 -07:00
|
|
|
}
|
|
|
|
}
|
2014-04-04 13:12:18 +03:00
|
|
|
ast::ExprVec(ref elements) => {
|
2012-08-28 15:54:45 -07:00
|
|
|
match dest {
|
|
|
|
Ignore => {
|
2013-08-03 12:45:23 -04:00
|
|
|
for element in elements.iter() {
|
2014-05-16 10:15:33 -07:00
|
|
|
bcx = expr::trans_into(bcx, &**element, Ignore);
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SaveIn(lldest) => {
|
2014-01-15 14:39:08 -05:00
|
|
|
let temp_scope = fcx.push_custom_cleanup_scope();
|
2013-08-03 12:45:23 -04:00
|
|
|
for (i, element) in elements.iter().enumerate() {
|
2014-11-17 21:39:01 +13:00
|
|
|
let lleltptr = GEPi(bcx, lldest, &[i]);
|
2014-10-15 02:25:34 -04:00
|
|
|
debug!("writing index {} with lleltptr={}",
|
2014-06-21 03:39:03 -07:00
|
|
|
i, bcx.val_to_string(lleltptr));
|
2014-05-16 10:15:33 -07:00
|
|
|
bcx = expr::trans_into(bcx, &**element,
|
2012-08-28 15:54:45 -07:00
|
|
|
SaveIn(lleltptr));
|
Emit LLVM lifetime intrinsics to improve stack usage and codegen in general
Lifetime intrinsics help to reduce stack usage, because LLVM can apply
stack coloring to reuse the stack slots of dead allocas for new ones.
For example these functions now both use the same amount of stack, while
previous `bar()` used five times as much as `foo()`:
````rust
fn foo() {
println("{}", 5);
}
fn bar() {
println("{}", 5);
println("{}", 5);
println("{}", 5);
println("{}", 5);
println("{}", 5);
}
````
On top of that, LLVM can also optimize out certain operations when it
knows that memory is dead after a certain point. For example, it can
sometimes remove the zeroing used to cancel the drop glue. This is
possible when the glue drop itself was already removed because the
zeroing dominated the drop glue call. For example in:
````rust
pub fn bar(x: (Box<int>, int)) -> (Box<int>, int) {
x
}
````
With optimizations, this currently results in:
````llvm
define void @_ZN3bar20h330fa42547df8179niaE({ i64*, i64 }* noalias nocapture nonnull sret, { i64*, i64 }* noalias nocapture nonnull) unnamed_addr #0 {
"_ZN29_$LP$Box$LT$int$GT$$C$int$RP$39glue_drop.$x22glue_drop$x22$LP$1347$RP$17h88cf42702e5a322aE.exit":
%2 = bitcast { i64*, i64 }* %1 to i8*
%3 = bitcast { i64*, i64 }* %0 to i8*
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 8, i1 false)
tail call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 16, i32 8, i1 false)
ret void
}
````
But with lifetime intrinsics we get:
````llvm
define void @_ZN3bar20h330fa42547df8179niaE({ i64*, i64 }* noalias nocapture nonnull sret, { i64*, i64 }* noalias nocapture nonnull) unnamed_addr #0 {
"_ZN29_$LP$Box$LT$int$GT$$C$int$RP$39glue_drop.$x22glue_drop$x22$LP$1347$RP$17h88cf42702e5a322aE.exit":
%2 = bitcast { i64*, i64 }* %1 to i8*
%3 = bitcast { i64*, i64 }* %0 to i8*
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 8, i1 false)
tail call void @llvm.lifetime.end(i64 16, i8* %2)
ret void
}
````
Fixes #15665
2014-05-01 19:32:07 +02:00
|
|
|
let scope = cleanup::CustomScope(temp_scope);
|
|
|
|
fcx.schedule_lifetime_end(scope, lleltptr);
|
|
|
|
fcx.schedule_drop_mem(scope, lleltptr, vt.unit_ty);
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
2014-01-15 14:39:08 -05:00
|
|
|
fcx.pop_custom_cleanup_scope(temp_scope);
|
2012-08-03 18:48:17 -07:00
|
|
|
}
|
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
return bcx;
|
|
|
|
}
|
2014-05-16 10:15:33 -07:00
|
|
|
ast::ExprRepeat(ref element, ref count_expr) => {
|
2012-08-28 15:54:45 -07:00
|
|
|
match dest {
|
|
|
|
Ignore => {
|
2014-05-16 10:15:33 -07:00
|
|
|
return expr::trans_into(bcx, &**element, Ignore);
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
SaveIn(lldest) => {
|
2014-10-29 21:45:35 -07:00
|
|
|
match ty::eval_repeat_count(bcx.tcx(), &**count_expr) {
|
|
|
|
0 => bcx,
|
|
|
|
1 => expr::trans_into(bcx, &**element, SaveIn(lldest)),
|
|
|
|
count => {
|
|
|
|
let elem = unpack_datum!(bcx, expr::trans(bcx, &**element));
|
|
|
|
assert!(!ty::type_moves_by_default(bcx.tcx(), elem.ty));
|
|
|
|
|
|
|
|
let bcx = iter_vec_loop(bcx, lldest, vt,
|
|
|
|
C_uint(bcx.ccx(), count),
|
|
|
|
|set_bcx, lleltptr, _| {
|
|
|
|
elem.shallow_copy(set_bcx, lleltptr)
|
|
|
|
});
|
|
|
|
|
|
|
|
elem.add_clean_if_rvalue(bcx, element.id);
|
|
|
|
bcx
|
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_ => {
|
|
|
|
bcx.tcx().sess.span_bug(content_expr.span,
|
2014-02-06 10:38:08 +01:00
|
|
|
"unexpected vec content");
|
2012-08-03 18:48:17 -07:00
|
|
|
}
|
2011-08-22 11:48:00 -07:00
|
|
|
}
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
2012-04-19 15:42:02 -07:00
|
|
|
|
2014-09-29 22:11:30 +03:00
|
|
|
pub fn vec_types_from_expr<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
vec_expr: &ast::Expr)
|
|
|
|
-> VecTypes<'tcx> {
|
2012-08-28 15:54:45 -07:00
|
|
|
let vec_ty = node_id_type(bcx, vec_expr.id);
|
2014-04-06 13:54:41 +03:00
|
|
|
vec_types(bcx, ty::sequence_element_type(bcx.tcx(), vec_ty))
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
2012-04-19 15:42:02 -07:00
|
|
|
|
2014-09-29 22:11:30 +03:00
|
|
|
pub fn vec_types<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
unit_ty: Ty<'tcx>)
|
|
|
|
-> VecTypes<'tcx> {
|
2012-08-28 15:54:45 -07:00
|
|
|
let ccx = bcx.ccx();
|
|
|
|
let llunit_ty = type_of::type_of(ccx, unit_ty);
|
2013-01-08 00:24:43 -08:00
|
|
|
let llunit_size = nonzero_llsize_of(ccx, llunit_ty);
|
2013-10-29 23:34:43 -07:00
|
|
|
let llunit_alloc_size = llsize_of_alloc(ccx, llunit_ty);
|
2013-01-08 00:24:43 -08:00
|
|
|
|
2014-04-06 13:54:41 +03:00
|
|
|
VecTypes {
|
|
|
|
unit_ty: unit_ty,
|
|
|
|
llunit_ty: llunit_ty,
|
|
|
|
llunit_size: llunit_size,
|
|
|
|
llunit_alloc_size: llunit_alloc_size
|
|
|
|
}
|
2011-08-22 11:48:00 -07:00
|
|
|
}
|
2011-09-27 20:21:44 +02:00
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn elements_required(bcx: Block, content_expr: &ast::Expr) -> uint {
|
2012-08-28 15:54:45 -07:00
|
|
|
//! Figure out the number of elements we need to store this content
|
|
|
|
|
2013-03-20 01:17:42 -04:00
|
|
|
match content_expr.node {
|
2014-09-07 20:09:06 +03:00
|
|
|
ast::ExprLit(ref lit) => {
|
2014-01-03 15:08:48 -08:00
|
|
|
match lit.node {
|
2014-01-10 14:02:36 -08:00
|
|
|
ast::LitStr(ref s, _) => s.get().len(),
|
2014-01-03 15:08:48 -08:00
|
|
|
_ => {
|
|
|
|
bcx.tcx().sess.span_bug(content_expr.span,
|
2014-02-06 10:38:08 +01:00
|
|
|
"unexpected evec content")
|
2014-01-03 15:08:48 -08:00
|
|
|
}
|
|
|
|
}
|
2012-12-27 14:36:00 -05:00
|
|
|
},
|
2014-04-04 13:12:18 +03:00
|
|
|
ast::ExprVec(ref es) => es.len(),
|
2014-05-16 10:15:33 -07:00
|
|
|
ast::ExprRepeat(_, ref count_expr) => {
|
|
|
|
ty::eval_repeat_count(bcx.tcx(), &**count_expr)
|
2012-08-28 15:54:45 -07:00
|
|
|
}
|
|
|
|
_ => bcx.tcx().sess.span_bug(content_expr.span,
|
2014-02-06 10:38:08 +01:00
|
|
|
"unexpected vec content")
|
2012-04-09 17:32:49 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn get_fixed_base_and_len(bcx: Block,
|
2014-04-25 15:14:52 +12:00
|
|
|
llval: ValueRef,
|
|
|
|
vec_length: uint)
|
|
|
|
-> (ValueRef, ValueRef) {
|
2014-01-15 14:39:08 -05:00
|
|
|
/*!
|
2014-04-11 09:01:31 +03:00
|
|
|
* Converts a fixed-length vector into the slice pair.
|
|
|
|
* The vector should be stored in `llval` which should be by ref.
|
2014-01-15 14:39:08 -05:00
|
|
|
*/
|
2012-04-17 15:07:38 -07:00
|
|
|
|
2012-08-28 15:54:45 -07:00
|
|
|
let ccx = bcx.ccx();
|
2012-04-17 15:07:38 -07:00
|
|
|
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
let base = expr::get_dataptr(bcx, llval);
|
2014-04-25 15:14:52 +12:00
|
|
|
let len = C_uint(ccx, vec_length);
|
2014-04-11 09:01:31 +03:00
|
|
|
(base, len)
|
2012-04-17 15:07:38 -07:00
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
fn get_slice_base_and_len(bcx: Block,
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
llval: ValueRef)
|
|
|
|
-> (ValueRef, ValueRef) {
|
2014-11-10 18:14:31 +01:00
|
|
|
let base = Load(bcx, GEPi(bcx, llval, &[0u, abi::FAT_PTR_ADDR]));
|
|
|
|
let len = Load(bcx, GEPi(bcx, llval, &[0u, abi::FAT_PTR_EXTRA]));
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
(base, len)
|
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn get_base_and_len(bcx: Block,
|
2014-01-15 14:39:08 -05:00
|
|
|
llval: ValueRef,
|
2014-09-13 21:09:25 +03:00
|
|
|
vec_ty: Ty)
|
2014-01-07 08:54:58 -08:00
|
|
|
-> (ValueRef, ValueRef) {
|
2014-01-15 14:39:08 -05:00
|
|
|
/*!
|
|
|
|
* Converts a vector into the slice pair. The vector should be
|
|
|
|
* stored in `llval` which should be by-reference. If you have a
|
|
|
|
* datum, you would probably prefer to call
|
|
|
|
* `Datum::get_base_and_len()` which will handle any conversions
|
|
|
|
* for you.
|
|
|
|
*/
|
2013-10-16 12:04:51 -04:00
|
|
|
|
|
|
|
let ccx = bcx.ccx();
|
|
|
|
|
2014-10-31 10:51:16 +02:00
|
|
|
match vec_ty.sty {
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
ty::ty_vec(_, Some(n)) => get_fixed_base_and_len(bcx, llval, n),
|
2014-10-31 10:51:16 +02:00
|
|
|
ty::ty_open(ty) => match ty.sty {
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
ty::ty_vec(_, None) | ty::ty_str => get_slice_base_and_len(bcx, llval),
|
|
|
|
_ => ccx.sess().bug("unexpected type in get_base_and_len")
|
|
|
|
},
|
|
|
|
|
|
|
|
// Only used for pattern matching.
|
2014-10-31 10:51:16 +02:00
|
|
|
ty::ty_uniq(ty) | ty::ty_rptr(_, ty::mt{ty, ..}) => match ty.sty {
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
ty::ty_vec(_, None) | ty::ty_str => get_slice_base_and_len(bcx, llval),
|
|
|
|
ty::ty_vec(_, Some(n)) => {
|
2014-11-17 21:39:01 +13:00
|
|
|
let base = GEPi(bcx, Load(bcx, llval), &[0u, 0u]);
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
(base, C_uint(ccx, n))
|
2014-04-27 10:19:15 +12:00
|
|
|
}
|
2014-04-25 15:14:52 +12:00
|
|
|
_ => ccx.sess().bug("unexpected type in get_base_and_len"),
|
2014-04-09 19:15:31 +12:00
|
|
|
},
|
|
|
|
_ => ccx.sess().bug("unexpected type in get_base_and_len"),
|
2013-10-16 12:04:51 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub type iter_vec_block<'a, 'blk, 'tcx> =
|
2014-09-29 22:11:30 +03:00
|
|
|
|Block<'blk, 'tcx>, ValueRef, Ty<'tcx>|: 'a -> Block<'blk, 'tcx>;
|
2014-09-06 19:13:04 +03:00
|
|
|
|
|
|
|
pub fn iter_vec_loop<'a, 'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
data_ptr: ValueRef,
|
2014-09-29 22:11:30 +03:00
|
|
|
vt: &VecTypes<'tcx>,
|
2014-09-06 19:13:04 +03:00
|
|
|
count: ValueRef,
|
|
|
|
f: iter_vec_block<'a, 'blk, 'tcx>)
|
|
|
|
-> Block<'blk, 'tcx> {
|
2013-10-29 23:34:43 -07:00
|
|
|
let _icx = push_ctxt("tvec::iter_vec_loop");
|
2014-01-15 14:39:08 -05:00
|
|
|
let fcx = bcx.fcx;
|
2013-10-29 23:34:43 -07:00
|
|
|
|
2014-01-15 14:39:08 -05:00
|
|
|
let next_bcx = fcx.new_temp_block("expr_repeat: while next");
|
|
|
|
let loop_bcx = fcx.new_temp_block("expr_repeat");
|
|
|
|
let cond_bcx = fcx.new_temp_block("expr_repeat: loop cond");
|
|
|
|
let body_bcx = fcx.new_temp_block("expr_repeat: body: set");
|
|
|
|
let inc_bcx = fcx.new_temp_block("expr_repeat: body: inc");
|
2013-10-29 23:34:43 -07:00
|
|
|
Br(bcx, loop_bcx.llbb);
|
|
|
|
|
|
|
|
let loop_counter = {
|
|
|
|
// i = 0
|
2014-09-05 09:18:53 -07:00
|
|
|
let i = alloca(loop_bcx, bcx.ccx().int_type(), "__i");
|
2014-10-14 23:36:11 +03:00
|
|
|
Store(loop_bcx, C_uint(bcx.ccx(), 0u), i);
|
2013-10-29 23:34:43 -07:00
|
|
|
|
|
|
|
Br(loop_bcx, cond_bcx.llbb);
|
|
|
|
i
|
|
|
|
};
|
|
|
|
|
|
|
|
{ // i < count
|
|
|
|
let lhs = Load(cond_bcx, loop_counter);
|
|
|
|
let rhs = count;
|
2014-07-07 17:58:01 -07:00
|
|
|
let cond_val = ICmp(cond_bcx, llvm::IntULT, lhs, rhs);
|
2013-10-29 23:34:43 -07:00
|
|
|
|
|
|
|
CondBr(cond_bcx, cond_val, body_bcx.llbb, next_bcx.llbb);
|
|
|
|
}
|
|
|
|
|
|
|
|
{ // loop body
|
|
|
|
let i = Load(body_bcx, loop_counter);
|
|
|
|
let lleltptr = if vt.llunit_alloc_size == 0 {
|
|
|
|
data_ptr
|
|
|
|
} else {
|
2014-11-17 21:39:01 +13:00
|
|
|
InBoundsGEP(body_bcx, data_ptr, &[i])
|
2013-10-29 23:34:43 -07:00
|
|
|
};
|
|
|
|
let body_bcx = f(body_bcx, lleltptr, vt.unit_ty);
|
|
|
|
|
|
|
|
Br(body_bcx, inc_bcx.llbb);
|
|
|
|
}
|
|
|
|
|
|
|
|
{ // i += 1
|
|
|
|
let i = Load(inc_bcx, loop_counter);
|
2014-10-14 23:36:11 +03:00
|
|
|
let plusone = Add(inc_bcx, i, C_uint(bcx.ccx(), 1u));
|
2013-10-29 23:34:43 -07:00
|
|
|
Store(inc_bcx, plusone, loop_counter);
|
|
|
|
|
|
|
|
Br(inc_bcx, cond_bcx.llbb);
|
|
|
|
}
|
|
|
|
|
|
|
|
next_bcx
|
|
|
|
}
|
|
|
|
|
2014-09-06 19:13:04 +03:00
|
|
|
pub fn iter_vec_raw<'a, 'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
|
|
|
|
data_ptr: ValueRef,
|
2014-09-29 22:11:30 +03:00
|
|
|
unit_ty: Ty<'tcx>,
|
2014-09-06 19:13:04 +03:00
|
|
|
len: ValueRef,
|
|
|
|
f: iter_vec_block<'a, 'blk, 'tcx>)
|
|
|
|
-> Block<'blk, 'tcx> {
|
2013-06-17 16:23:24 +12:00
|
|
|
let _icx = push_ctxt("tvec::iter_vec_raw");
|
2014-01-15 14:39:08 -05:00
|
|
|
let fcx = bcx.fcx;
|
2012-04-19 15:42:02 -07:00
|
|
|
|
2014-04-06 13:54:41 +03:00
|
|
|
let vt = vec_types(bcx, unit_ty);
|
2014-04-25 15:14:52 +12:00
|
|
|
let fill = Mul(bcx, len, vt.llunit_size);
|
|
|
|
|
2014-01-19 19:21:14 +11:00
|
|
|
if vt.llunit_alloc_size == 0 {
|
2013-10-29 23:34:43 -07:00
|
|
|
// Special-case vectors with elements of size 0 so they don't go out of bounds (#9890)
|
|
|
|
iter_vec_loop(bcx, data_ptr, &vt, fill, f)
|
|
|
|
} else {
|
|
|
|
// Calculate the last pointer address we want to handle.
|
|
|
|
// FIXME (#3729): Optimize this when the size of the unit type is
|
|
|
|
// statically known to not use pointer casts, which tend to confuse
|
|
|
|
// LLVM.
|
|
|
|
let data_end_ptr = pointer_add_byte(bcx, data_ptr, fill);
|
|
|
|
|
|
|
|
// Now perform the iteration.
|
2014-01-15 14:39:08 -05:00
|
|
|
let header_bcx = fcx.new_temp_block("iter_vec_loop_header");
|
2013-10-29 23:34:43 -07:00
|
|
|
Br(bcx, header_bcx.llbb);
|
|
|
|
let data_ptr =
|
2014-11-17 21:39:01 +13:00
|
|
|
Phi(header_bcx, val_ty(data_ptr), &[data_ptr], &[bcx.llbb]);
|
2013-10-29 23:34:43 -07:00
|
|
|
let not_yet_at_end =
|
2014-07-07 17:58:01 -07:00
|
|
|
ICmp(header_bcx, llvm::IntULT, data_ptr, data_end_ptr);
|
2014-01-15 14:39:08 -05:00
|
|
|
let body_bcx = fcx.new_temp_block("iter_vec_loop_body");
|
|
|
|
let next_bcx = fcx.new_temp_block("iter_vec_next");
|
2013-10-29 23:34:43 -07:00
|
|
|
CondBr(header_bcx, not_yet_at_end, body_bcx.llbb, next_bcx.llbb);
|
|
|
|
let body_bcx = f(body_bcx, data_ptr, vt.unit_ty);
|
|
|
|
AddIncomingToPhi(data_ptr, InBoundsGEP(body_bcx, data_ptr,
|
2014-11-17 21:39:01 +13:00
|
|
|
&[C_int(bcx.ccx(), 1i)]),
|
2013-10-29 23:34:43 -07:00
|
|
|
body_bcx.llbb);
|
|
|
|
Br(body_bcx, header_bcx.llbb);
|
|
|
|
next_bcx
|
|
|
|
}
|
2012-04-19 15:42:02 -07:00
|
|
|
}
|