---

yaml
---
r: 89791
b: refs/heads/master
c: 88e383e
h: refs/heads/master
i:
  89789: aba4040
  89787: 5b3de15
  89783: 47003b3
  89775: 33f7092
  89759: 89f7d60
  89727: c3de7fe
v: v3

Author: bors

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: e34834375db649a16d45c902f7f0209a44c7e42e
+refs/heads/master: 88e383ef1e702666159bdc899d81e30927479501
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: a6d3e57dca68fde4effdda3e4ae2887aa535fcd6
 refs/heads/try: b160761e35efcd1207112b3b782c06633cf441a8

trunk/.gitignore

@@ -30,6 +30,7 @@
 *.cps
 *.log
 *.pdf
+*.epub
 *.html
 *.pg
 *.toc

trunk/Makefile.in

@@ -125,6 +125,7 @@ ifdef TRACE
   CFG_RUSTC_FLAGS += -Z trace
 endif
 ifndef DEBUG_BORROWS
+  RUSTFLAGS_STAGE0 += -Z no-debug-borrows
   RUSTFLAGS_STAGE1 += -Z no-debug-borrows
   RUSTFLAGS_STAGE2 += -Z no-debug-borrows
 endif

trunk/doc/tutorial-ffi.md

@@ -19,10 +19,9 @@ extern {
     fn snappy_max_compressed_length(source_length: size_t) -> size_t;
 }
 
-#[fixed_stack_segment]
 fn main() {
     let x = unsafe { snappy_max_compressed_length(100) };
-    println(fmt!("max compressed length of a 100 byte buffer: %?", x));
+    println!("max compressed length of a 100 byte buffer: {}", x);
 }
 ~~~~
 
@@ -36,11 +35,6 @@ interfaces that aren't thread-safe, and almost any function that takes a pointer
 valid for all possible inputs since the pointer could be dangling, and raw pointers fall outside of
 Rust's safe memory model.
 
-Finally, the `#[fixed_stack_segment]` annotation that appears on
-`main()` instructs the Rust compiler that when `main()` executes, it
-should request a "very large" stack segment.  More details on
-stack management can be found in the following sections.
-
 When declaring the argument types to a foreign function, the Rust compiler will not check if the
 declaration is correct, so specifying it correctly is part of keeping the binding correct at
 runtime.
@@ -81,8 +75,6 @@ length is number of elements currently contained, and the capacity is the total
 the allocated memory. The length is less than or equal to the capacity.
 
 ~~~~ {.xfail-test}
-#[fixed_stack_segment]
-#[inline(never)]
 pub fn validate_compressed_buffer(src: &[u8]) -> bool {
     unsafe {
         snappy_validate_compressed_buffer(vec::raw::to_ptr(src), src.len() as size_t) == 0
@@ -94,36 +86,6 @@ The `validate_compressed_buffer` wrapper above makes use of an `unsafe` block, b
 guarantee that calling it is safe for all inputs by leaving off `unsafe` from the function
 signature.
 
-The `validate_compressed_buffer` wrapper is also annotated with two
-attributes `#[fixed_stack_segment]` and `#[inline(never)]`. The
-purpose of these attributes is to guarantee that there will be
-sufficient stack for the C function to execute. This is necessary
-because Rust, unlike C, does not assume that the stack is allocated in
-one continuous chunk. Instead, we rely on a *segmented stack* scheme,
-in which the stack grows and shrinks as necessary.  C code, however,
-expects one large stack, and so callers of C functions must request a
-large stack segment to ensure that the C routine will not run off the
-end of the stack.
-
-The compiler includes a lint mode that will report an error if you
-call a C function without a `#[fixed_stack_segment]` attribute. More
-details on the lint mode are given in a later section.
-
-You may be wondering why we include a `#[inline(never)]` directive.
-This directive informs the compiler never to inline this function.
-While not strictly necessary, it is usually a good idea to use an
-`#[inline(never)]` directive in concert with `#[fixed_stack_segment]`.
-The reason is that if a fn annotated with `fixed_stack_segment` is
-inlined, then its caller also inherits the `fixed_stack_segment`
-annotation. This means that rather than requesting a large stack
-segment only for the duration of the call into C, the large stack
-segment would be used for the entire duration of the caller. This is
-not necessarily *bad* -- it can for example be more efficient,
-particularly if `validate_compressed_buffer()` is called multiple
-times in a row -- but it does work against the purpose of the
-segmented stack scheme, which is to keep stacks small and thus
-conserve address space.
-
 The `snappy_compress` and `snappy_uncompress` functions are more complex, since a buffer has to be
 allocated to hold the output too.
 
@@ -134,8 +96,6 @@ the true length after compression for setting the length.
 
 ~~~~ {.xfail-test}
 pub fn compress(src: &[u8]) -> ~[u8] {
-    #[fixed_stack_segment]; #[inline(never)];
-
     unsafe {
         let srclen = src.len() as size_t;
         let psrc = vec::raw::to_ptr(src);
@@ -156,8 +116,6 @@ format and `snappy_uncompressed_length` will retrieve the exact buffer size requ
 
 ~~~~ {.xfail-test}
 pub fn uncompress(src: &[u8]) -> Option<~[u8]> {
-    #[fixed_stack_segment]; #[inline(never)];
-
     unsafe {
         let srclen = src.len() as size_t;
         let psrc = vec::raw::to_ptr(src);
@@ -181,98 +139,28 @@ pub fn uncompress(src: &[u8]) -> Option<~[u8]> {
 For reference, the examples used here are also available as an [library on
 GitHub](https://github.com/thestinger/rust-snappy).
 
-# Automatic wrappers
-
-Sometimes writing Rust wrappers can be quite tedious.  For example, if
-function does not take any pointer arguments, often there is no need
-for translating types. In such cases, it is usually still a good idea
-to have a Rust wrapper so as to manage the segmented stacks, but you
-can take advantage of the (standard) `externfn!` macro to remove some
-of the tedium.
-
-In the initial section, we showed an extern block that added a call
-to a specific snappy API:
-
-~~~~ {.xfail-test}
-use std::libc::size_t;
-
-#[link_args = "-lsnappy"]
-extern {
-    fn snappy_max_compressed_length(source_length: size_t) -> size_t;
-}
-
-#[fixed_stack_segment]
-fn main() {
-    let x = unsafe { snappy_max_compressed_length(100) };
-    println(fmt!("max compressed length of a 100 byte buffer: %?", x));
-}
-~~~~
-
-To avoid the need to create a wrapper fn for `snappy_max_compressed_length()`,
-and also to avoid the need to think about `#[fixed_stack_segment]`, we
-could simply use the `externfn!` macro instead, as shown here:
-
-~~~~ {.xfail-test}
-use std::libc::size_t;
-
-externfn!(#[link_args = "-lsnappy"]
-          fn snappy_max_compressed_length(source_length: size_t) -> size_t)
-
-fn main() {
-    let x = unsafe { snappy_max_compressed_length(100) };
-    println(fmt!("max compressed length of a 100 byte buffer: %?", x));
-}
-~~~~
-
-As you can see from the example, `externfn!` replaces the extern block
-entirely. After macro expansion, it will create something like this:
-
-~~~~ {.xfail-test}
-use std::libc::size_t;
-
-// Automatically generated by
-//   externfn!(#[link_args = "-lsnappy"]
-//             fn snappy_max_compressed_length(source_length: size_t) -> size_t)
-unsafe fn snappy_max_compressed_length(source_length: size_t) -> size_t {
-    #[fixed_stack_segment]; #[inline(never)];
-    return snappy_max_compressed_length(source_length);
-
-    #[link_args = "-lsnappy"]
-    extern {
-        fn snappy_max_compressed_length(source_length: size_t) -> size_t;
-    }
-}
-
-fn main() {
-    let x = unsafe { snappy_max_compressed_length(100) };
-    println(fmt!("max compressed length of a 100 byte buffer: %?", x));
-}
-~~~~
-
-# Segmented stacks and the linter
-
-By default, whenever you invoke a non-Rust fn, the `cstack` lint will
-check that one of the following conditions holds:
-
-1. The call occurs inside of a fn that has been annotated with
-   `#[fixed_stack_segment]`;
-2. The call occurs inside of an `extern fn`;
-3. The call occurs within a stack closure created by some other
-   safe fn.
-
-All of these conditions ensure that you are running on a large stack
-segment. However, they are sometimes too strict. If your application
-will be making many calls into C, it is often beneficial to promote
-the `#[fixed_stack_segment]` attribute higher up the call chain.  For
-example, the Rust compiler actually labels main itself as requiring a
-`#[fixed_stack_segment]`. In such cases, the linter is just an
-annoyance, because all C calls that occur from within the Rust
-compiler are made on a large stack. Another situation where this
-frequently occurs is on a 64-bit architecture, where large stacks are
-the default. In cases, you can disable the linter by including a
-`#[allow(cstack)]` directive somewhere, which permits violations of
-the "cstack" rules given above (you can also use `#[warn(cstack)]` to
-convert the errors into warnings, if you prefer).
+# Stack management
+
+Rust tasks by default run on a "large stack". This is actually implemented as a
+reserving a large segment of the address space and then lazily mapping in pages
+as they are needed. When calling an external C function, the code is invoked on
+the same stack as the rust stack. This means that there is no extra
+stack-switching mechanism in place because it is assumed that the large stack
+for the rust task is plenty for the C function to have.
+
+A planned future improvement (net yet implemented at the time of this writing)
+is to have a guard page at the end of every rust stack. No rust function will
+hit this guard page (due to rust's usage of LLVM's __morestack). The intention
+for this unmapped page is to prevent infinite recursion in C from overflowing
+onto other rust stacks. If the guard page is hit, then the process will be
+terminated with a message saying that the guard page was hit.
+
+For normal external function usage, this all means that there shouldn't be any
+need for any extra effort on a user's perspective. The C stack naturally
+interleaves with the rust stack, and it's "large enough" for both to
+interoperate. If, however, it is determined that a larger stack is necessary,
+there are appropriate functions in the task spawning API to control the size of
+the stack of the task which is spawned.
 
 # Destructors
 
@@ -296,9 +184,6 @@ pub struct Unique<T> {
 
 impl<T: Send> Unique<T> {
     pub fn new(value: T) -> Unique<T> {
-        #[fixed_stack_segment];
-        #[inline(never)];
-
         unsafe {
             let ptr = malloc(std::mem::size_of::<T>() as size_t) as *mut T;
             assert!(!ptr::is_null(ptr));
@@ -322,9 +207,6 @@ impl<T: Send> Unique<T> {
 #[unsafe_destructor]
 impl<T: Send> Drop for Unique<T> {
     fn drop(&mut self) {
-        #[fixed_stack_segment];
-        #[inline(never)];
-
         unsafe {
             let x = intrinsics::init(); // dummy value to swap in
             // moving the object out is needed to call the destructor
@@ -384,8 +266,8 @@ extern {
 }
 
 fn main() {
-    println(fmt!("You have readline version %d installed.",
-                 rl_readline_version as int));
+    println!("You have readline version {} installed.",
+             rl_readline_version as int);
 }
 ~~~
 
@@ -418,15 +300,32 @@ calling foreign functions. Some foreign functions, most notably the Windows API,
 conventions. Rust provides a way to tell the compiler which convention to use:
 
 ~~~~
-#[cfg(target_os = "win32")]
+#[cfg(target_os = "win32", target_arch = "x86")]
 #[link_name = "kernel32"]
 extern "stdcall" {
     fn SetEnvironmentVariableA(n: *u8, v: *u8) -> int;
 }
 ~~~~
 
-This applies to the entire `extern` block, and must be either `"cdecl"` or
-`"stdcall"`. The compiler may eventually support other calling conventions.
+This applies to the entire `extern` block. The list of supported ABI constraints
+are:
+
+* `stdcall`
+* `aapcs`
+* `cdecl`
+* `fastcall`
+* `Rust`
+* `rust-intrinsic`
+* `system`
+* `C`
+
+Most of the abis in this list are self-explanatory, but the `system` abi may
+seem a little odd. This constraint selects whatever the appropriate ABI is for
+interoperating with the target's libraries. For example, on win32 with a x86
+architecture, this means that the abi used would be `stdcall`. On x86_64,
+however, windows uses the `C` calling convention, so `C` would be used. This
+means that in our previous example, we could have used `extern "system" { ... }`
+to define a block for all windows systems, not just x86 ones.
 
 # Interoperability with foreign code
 

trunk/mk/clean.mk

@@ -53,7 +53,7 @@ clean-misc:
 	$(Q)rm -Rf tmp/*
 	$(Q)rm -Rf rust-stage0-*.tar.bz2 $(PKG_NAME)-*.tar.gz dist
 	$(Q)rm -Rf $(foreach ext, \
-                 html aux cp fn ky log pdf pg toc tp vr cps, \
+                 html aux cp fn ky log pdf pg toc tp vr cps epub, \
                  $(wildcard doc/*.$(ext)))
 	$(Q)find doc/std doc/extra -mindepth 1 | xargs rm -Rf
 	$(Q)rm -Rf doc/version.md

trunk/mk/docs.mk

@@ -64,6 +64,20 @@ doc/rust.tex: rust.md doc/version.md
          --from=markdown --to=latex \
          --output=$@
 
+DOCS += doc/rust.epub
+doc/rust.epub: rust.md doc/version_info.html doc/rust.css doc/manual.inc
+	@$(call E, pandoc: $@)
+	$(Q)$(CFG_NODE) $(S)doc/prep.js --highlight $< | \
+	"$(CFG_PANDOC)" \
+         --standalone --toc \
+         --section-divs \
+         --number-sections \
+         --from=markdown --to=epub \
+         --css=rust.css --include-in-header=doc/manual.inc \
+         --include-before-body=doc/version_info.html \
+         --output=$@
+
+
 DOCS += doc/tutorial.tex
 doc/tutorial.tex: tutorial.md doc/version.md
 	@$(call E, pandoc: $@)
@@ -98,6 +112,17 @@ doc/tutorial.html: tutorial.md doc/version_info.html doc/rust.css
            --include-before-body=doc/version_info.html \
            --output=$@
 
+DOCS += doc/tutorial.epub
+doc/tutorial.epub: tutorial.md doc/version_info.html doc/rust.css
+	@$(call E, pandoc: $@)
+	$(Q)$(CFG_NODE) $(S)doc/prep.js --highlight $< | \
+          $(CFG_PANDOC) --standalone --toc \
+           --section-divs --number-sections \
+           --from=markdown --to=epub --css=rust.css \
+           --include-before-body=doc/version_info.html \
+           --output=$@
+
+
 DOCS_L10N += doc/l10n/ja/tutorial.html
 doc/l10n/ja/tutorial.html: doc/l10n/ja/tutorial.md doc/version_info.html doc/rust.css
 	@$(call E, pandoc: $@)

trunk/mk/rt.mk

@@ -207,7 +207,7 @@ LIBUV_MAKEFILE_$(1) := $$(CFG_BUILD_DIR)$$(RT_OUTPUT_DIR_$(1))/libuv/Makefile
 
 $$(LIBUV_MAKEFILE_$(1)): $$(LIBUV_DEPS)
 	(cd $(S)src/libuv/ && \
-	 $$(CFG_PYTHON) ./gyp_uv -f make -Dtarget_arch=$$(LIBUV_ARCH_$(1)) \
+	 $$(CFG_PYTHON) ./gyp_uv.py -f make -Dtarget_arch=$$(LIBUV_ARCH_$(1)) \
 	   -D ninja \
 	   -DOS=$$(LIBUV_OSTYPE_$(1)) \
 	   -Goutput_dir=$$(@D) --generator-output $$(@D))
@@ -218,7 +218,7 @@ $$(LIBUV_MAKEFILE_$(1)): $$(LIBUV_DEPS)
 ifdef CFG_WINDOWSY_$(1)
 $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS)
 	$$(Q)$$(MAKE) -C $$(S)src/libuv -f Makefile.mingw \
-		CFLAGS="$$(CFG_GCCISH_CFLAGS) $$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)" \
+		CC="$$(CC) $$(CFG_GCCISH_CFLAGS) $$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)" \
 		AR="$$(AR_$(1))" \
 		V=$$(VERBOSE)
 	$$(Q)cp $$(S)src/libuv/libuv.a $$@