---

yaml
---
r: 5179
b: refs/heads/master
c: a10a6da
h: refs/heads/master
i:
  5177: 38ec4ea
  5175: 979643d
v: v3

Author: graydon

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: e9f9ec69724a0e65d930091f0fc9f512cf69a72b
+refs/heads/master: a10a6daba30e35b88ee41ffad1eda8243159659a

trunk/AUTHORS.txt

@@ -11,7 +11,7 @@ Brendan Eich <[email protected]>
 Brian Anderson <[email protected]>
 Chris Double <[email protected]>
 Dave Herman <[email protected]>
-Eric Holk <eholk@mozilla.com>
+Eric Holk <eric.holk@gmail.com>
 Erick Tryzelaar <[email protected]>
 Jason Orendorff <[email protected]>
 Jeff Balogh <[email protected]>

trunk/Makefile.in

@@ -186,8 +186,15 @@ SREQ$(1) = stage$(1)/rustc$(X)          \
            $$(MKFILES)
 endif
 
+ifeq ($(1),0)
+# Don't run the the stage0 compiler under valgrind - that ship has sailed
+CFG_VALGRIND_COMPILE$(1) =
+else
+CFG_VALGRIND_COMPILE$(1) = $$(CFG_VALGRIND_COMPILE)
+endif
+
 STAGE$(1) := $$(Q)$$(call CFG_RUN_TARG,stage$(1), \
-                $$(CFG_VALGRIND_COMPILE) stage$(1)/rustc$$(X) \
+                $$(CFG_VALGRIND_COMPILE$(1)) stage$(1)/rustc$$(X) \
                 $$(CFG_RUSTC_FLAGS))
 endef
 

trunk/doc/rust.texi

@@ -642,6 +642,7 @@ The keywords are:
 @tab @code{syntax}
 @tab @code{mutable}
 @tab @code{native}
+@tab @code{unchecked}
 @item @code{mod}
 @tab @code{import}
 @tab @code{export}
@@ -679,7 +680,7 @@ The keywords are:
 @tab @code{with}
 @item @code{fn}
 @tab @code{iter}
-@tab @code{pred}
+@tab @code{pure}
 @tab @code{obj}
 @tab @code{resource}
 @item @code{if}
@@ -1252,15 +1253,6 @@ immediately destructed (if acyclic) or else collected using a general
 (cycle-aware) garbage-collector local to each task. Garbage collection within
 a local heap does not interrupt execution of other tasks.
 
-Immutable boxes are @dfn{shared}, and can be multiply-referenced by many
-different tasks. Like any other immutable type, they can pass over channels,
-and live as long as the last task referencing them within a given domain. When
-unreferenced, they are destroyed immediately (due to reference-counting) and
-returned to the heap memory allocator. Destruction of an immutable box also
-executes within the context of the task that drops the last reference to a
-shared heap allocation, so executing a long-running destructor does not
-interrupt execution of other tasks.
-
 
 @node       Ref.Mem.Own
 @subsection Ref.Mem.Own
@@ -1396,25 +1388,23 @@ fn main() @{
 @node       Ref.Mem.Acct
 @subsection Ref.Mem.Acct
 @c * Ref.Mem.Acct::                Memory accounting model.
-@cindex Domain
 @cindex Accounting
 @cindex Memory budget
 
-Every task belongs to a domain, and that domain tracks the amount of memory
-allocated and not yet released by tasks within it. @xref{Ref.Task.Dom}. Each
-domain has a memory budget. The @dfn{budget} of a domain is the maximum amount
-of memory that can be simultaneously allocated in the domain. If a task tries
-to allocate memory within a domain with an exceeded budget, the task will
-receive a signal.
+Every task tracks the amount of memory allocated and not yet released. Each
+task may have a memory budget. The @dfn{budget} of a task is the maximum
+amount of memory that can be simultaneously allocated in the task. If a task
+tries to allocate memory with an exceeded budget, the task will receive a
+signal.
 
 Within a task, accounting is strictly enforced: all memory allocated through
-the runtime library, both user data, sub-domains and runtime-support
-structures such as channel and signal queues, are charged to a task's domain.
+the runtime library, both user data and runtime-support structures such as
+channel and signal queues, are charged to a task.
 
-When a communication channel crosses from one domain to another, any value
+When a communication channel crosses from one task to another, any value
 sent over the channel is guaranteed to have been @emph{detached} from the
-domain's memory graph (singly referenced, and/or deep-copied), so its memory
-cost is transferred to the receiving domain.
+task's memory graph (singly referenced, and/or deep-copied), so its memory
+cost is transferred to the receiving task.
 
 
 @page
@@ -1439,7 +1429,6 @@ operating-system processes.
 @menu
 * Ref.Task.Comm::               Inter-task communication.
 * Ref.Task.Life::               Task lifecycle and state transitions.
-* Ref.Task.Dom::                Task domains.
 * Ref.Task.Sched::              Task scheduling model.
 * Ref.Task.Spawn::              Library interface for making new tasks.
 * Ref.Task.Send::               Library interface for sending messages.
@@ -1492,12 +1481,12 @@ transmit side. A channel contains a message queue and asynchronously sending a
 message merely inserts it into the sending channel's queue; message receipt is
 the responsibility of the receiving task.
 
-Queued messages in channels are charged to the domain of the @emph{sending}
-task. If too many messages are queued for transmission from a single sending
-task, without being received by a receiving task, the sending task may exceed
-its memory budget, which causes a run-time signal. To help control this
-possibility, a semi-synchronous send operation is possible, which blocks until
-there is room in the existing queue before sending send.
+Queued messages in channels are charged to the @emph{sending} task. If too
+many messages are queued for transmission from a single sending task, without
+being received by a receiving task, the sending task may exceed its memory
+budget, which causes a run-time signal. To help control this possibility, a
+semi-synchronous send operation is possible, which blocks until there is room
+in the existing queue before sending send.
 
 Messages are sent on channels and received on ports using standard library
 functions.
@@ -1560,31 +1549,6 @@ A task in the @emph{dead} state cannot transition to other states; it exists
 only to have its termination status inspected by other tasks, and/or to await
 reclamation when the last reference to it drops.
 
-@node       Ref.Task.Dom
-@subsection Ref.Task.Dom
-@c * Ref.Task.Dom::                Task domains
-
-@cindex Domain
-@cindex Process
-@cindex Thread
-
-Every task belongs to a domain. A @dfn{domain} is a structure that owns tasks,
-schedules tasks, tracks memory allocation within tasks and manages access to
-runtime services on behalf of tasks.
-
-Typically each domain runs on a separate operating-system @emph{thread}, or
-within an isolated operating-system @emph{process}. An easy way to think of a
-domain is as an abstraction over either an operating-system thread @emph{or} a
-process.
-
-The key feature of a domain is that it isolates memory references created by
-the Rust tasks within it. No Rust task can refer directly to memory outside
-its domain.
-
-Tasks can own sub-domains, which in turn own their own tasks. Every domain
-owns one @emph{root task}, which is the root of the tree of tasks owned by the
-domain.
-
 @node       Ref.Task.Sched
 @subsection Ref.Task.Sched
 @c * Ref.Task.Sched::              Task scheduling model.
@@ -1593,11 +1557,9 @@ domain.
 @cindex Preemption
 @cindex Yielding control
 
-Every task is @emph{scheduled} within its domain. @xref{Ref.Task.Dom}. The
-currently scheduled task is given a finite @emph{time slice} in which to
+The currently scheduled task is given a finite @emph{time slice} in which to
 execute, after which it is @emph{descheduled} at a loop-edge or similar
-preemption point, and another task within the domain is scheduled,
-pseudo-randomly.
+preemption point, and another task within is scheduled, pseudo-randomly.
 
 An executing task can @code{yield} control at any time, which deschedules it
 immediately. Entering any other non-executing state (blocked, dead) similarly
@@ -1616,7 +1578,7 @@ function. The passed function is referred to as the @dfn{entry function} for
 the spawned task, and any captured environment is carries is moved from the
 spawning task to the spawned task before the spawned task begins execution.
 
-The result of a @code{spawn} call is a @code{std::task::task_id} value.
+The result of a @code{spawn} call is a @code{std::task::task} value.
 
 An example of a @code{spawn} call:
 @example
@@ -1631,10 +1593,10 @@ fn helper(c: chan<u8>) @{
 
 let p: port<u8>;
 
-spawn(bind helper(p.mk_chan()));
+spawn(bind helper(chan(p)));
 // let task run, do other things.
 // ...
-let result = p.recv();
+let result = recv(p);
 
 @end example
 
@@ -1674,7 +1636,7 @@ An example of a @emph{receive}:
 @example
 import std::comm::*;
 let p: port<str> = @dots{};
-let s: str = p.recv();
+let s: str = recv(p);
 @end example
 
 
@@ -1931,7 +1893,7 @@ control).
 Any pure boolean function is called a @emph{predicate}, and may be used
 as part of the static typestate system. @xref{Ref.Typestate.Constr}. A
 predicate declaration is identical to a function declaration, except that it
-is declared with the keyword @code{pred} instead of @code{fn}. In addition,
+is declared with the additional keyword @code{pure}. In addition,
 the typechecker checks the body of a predicate with a restricted set of
 typechecking rules. A predicate
 @itemize
@@ -1942,11 +1904,65 @@ self-call expression; and
 
 An example of a predicate:
 @example
-pred lt_42(int x) -> bool @{
+pure fn lt_42(x: int) -> bool @{
     ret (x < 42);
 @}
 @end example
 
+A non-boolean function may also be declared with @code{pure fn}. This allows
+predicates to call non-boolean functions as long as they are pure. For example:
+@example
+pure fn pure_length<@@T>(ls: &list<T>) -> uint @{ /* ... */ @}
+
+pure fn nonempty_list<@@T>(ls: &list<T>) -> bool @{ pure_length(ls) > 0u @}
+@end example
+
+In this example, @code{nonempty_list} is a predicate---it can be used in a
+typestate constraint---but the auxiliary function @code{pure_length}@ is
+not.
+
+@emph{ToDo:} should actually define referential transparency.
+
+The effect checking rules previously enumerated are a restricted set of
+typechecking rules meant to approximate the universe of observably
+referentially transparent Rust procedures conservatively. Sometimes, these
+rules are @emph{too} restrictive. Rust allows programmers to violate these
+rules by writing predicates that the compiler cannot prove to be referentially
+transparent, using an escape-hatch feature called ``unchecked blocks''. When
+writing code that uses unchecked blocks, programmers should always be aware
+that they have an obligation to show that the code @emph{behaves} referentially
+transparently at all times, even if the compiler cannot @emph{prove}
+automatically that the code is referentially transparent. In the presence of
+unchecked blocks, the compiler provides no static guarantee that the code will
+behave as expected at runtime. Rather, the programmer has an independent
+obligation to verify the semantics of the predicates they write.
+
+@emph{ToDo:} last two sentences are vague.
+
+An example of a predicate that uses an unchecked block:
+@example
+fn pure_foldl<@@T, @@U>(ls: &list<T>, u: &U, f: &block(&T, &U) -> U) -> U @{
+    alt ls @{
+      nil. @{ u @}
+      cons(hd, tl) @{ f(hd, pure_foldl(*tl, f(hd, u), f)) @}
+    @}
+@}
+
+pure fn pure_length<@@T>(ls: &list<T>) -> uint @{
+    fn count<T>(_t: &T, u: &uint) -> uint @{ u + 1u @}
+    unchecked @{
+        pure_foldl(ls, 0u, count)
+    @}
+@}
+@end example
+
+Despite its name, @code{pure_foldl} is a @code{fn}, not a @code{pure fn},
+because there is no way in Rust to specify that the higher-order function
+argument @code{f} is a pure function. So, to use @code{foldl} in a pure list
+length function that a predicate could then use, we must use an
+@code{unchecked} block wrapped around the call to @code{pure_foldl} in the
+definition of @code{pure_length}.
+ 
 @node          Ref.Item.Iter
 @subsection    Ref.Item.Iter
 @c * Ref.Item.Iter::          Items defining iterators.
@@ -2748,7 +2764,7 @@ A @dfn{constraint} is a predicate applied to specific slots.
 For example, consider the following code:
 
 @example
-pred is_less_than(int a, int b) -> bool @{
+pure fn is_less_than(int a, int b) -> bool @{
      ret a < b;
 @}
 
@@ -3525,7 +3541,7 @@ and statically comparing implied states and their
 specifications. @xref{Ref.Typestate}.
 
 @example
-pred even(x: &int) -> bool @{
+pure fn even(x: &int) -> bool @{
     ret x & 1 == 0;
 @}
 
@@ -3724,7 +3740,7 @@ signal queue associated with each task. Sending a signal to a task inserts the
 signal into the task's signal queue and marks the task as having a pending
 signal. At the next scheduling opportunity, the runtime processes signals in
 the task's queue using its dispatch table. The signal queue memory is charged
-to the task's domain; if the queue grows too big, the task will fail.
+to the task; if the queue grows too big, the task will fail.
 
 @c ############################################################
 @c end main body of nodes

trunk/mk/platform.mk

@@ -9,7 +9,7 @@ CFG_DSYMUTIL := true
 
 ifeq ($(CFG_OSTYPE), FreeBSD)
   CFG_LIB_NAME=lib$(1).so
-  CFG_GCCISH_CFLAGS += -fPIC -march=i686 -I/usr/local/include -O2
+  CFG_GCCISH_CFLAGS += -fPIC -march=i686 -I/usr/local/include
   CFG_GCCISH_LINK_FLAGS += -shared -fPIC -lpthread -lrt
   ifeq ($(CFG_CPUTYPE), x86_64)
     CFG_GCCISH_CFLAGS += -m32
@@ -22,7 +22,7 @@ endif
 
 ifeq ($(CFG_OSTYPE), Linux)
   CFG_LIB_NAME=lib$(1).so
-  CFG_GCCISH_CFLAGS += -fPIC -march=i686 -O2
+  CFG_GCCISH_CFLAGS += -fPIC -march=i686
   CFG_GCCISH_LINK_FLAGS += -shared -fPIC -ldl -lpthread -lrt
   CFG_GCCISH_DEF_FLAG := -Wl,--export-dynamic,--dynamic-list=
   CFG_GCCISH_PRE_LIB_FLAGS := -Wl,-whole-archive
@@ -48,8 +48,8 @@ ifeq ($(CFG_OSTYPE), Darwin)
   # approaches welcome!
   #
   # NB: Currently GCC's optimizer breaks rustrt (task-comm-1 hangs) on Darwin.
-  CFG_GCC_CFLAGS += -m32 -O2
-  CFG_CLANG_CFLAGS += -m32 -O2
+  CFG_GCC_CFLAGS += -m32
+  CFG_CLANG_CFLAGS += -m32
   ifeq ($(CFG_CPUTYPE), x86_64)
     CFG_GCCISH_CFLAGS += -arch i386
     CFG_GCCISH_LINK_FLAGS += -arch i386
@@ -63,6 +63,13 @@ ifneq ($(findstring MINGW,$(CFG_OSTYPE)),)
   CFG_WINDOWSY := 1
 endif
 
+ifdef CFG_DISABLE_OPTIMIZE_CXX
+  $(info cfg: disabling C++ optimization (CFG_DISABLE_OPTIMIZE_CXX))
+  CFG_GCCISH_CFLAGS += -O0
+else
+  CFG_GCCISH_CFLAGS += -O2
+endif
+
 CFG_TESTLIB=$(CFG_BUILD_DIR)/$(strip \
  $(if $(findstring stage0,$(1)), \
        stage0/lib, \
@@ -94,7 +101,7 @@ ifdef CFG_UNIXY
       CFG_VALGRIND += wine
     endif
 
-    CFG_GCCISH_CFLAGS := -fno-strict-aliasing -march=i586 -O2
+    CFG_GCCISH_CFLAGS := -fno-strict-aliasing -march=i586
     CFG_GCCISH_PRE_LIB_FLAGS :=
     CFG_GCCISH_POST_LIB_FLAGS :=
     CFG_GCCISH_DEF_FLAG :=
@@ -130,7 +137,7 @@ ifdef CFG_WINDOWSY
     CFG_PATH_MUNGE := $(strip perl -i.bak -p             \
                              -e 's@\\(\S)@/\1@go;'       \
                              -e 's@^/([a-zA-Z])/@\1:/@o;')
-    CFG_GCCISH_CFLAGS += -march=i686 -O2
+    CFG_GCCISH_CFLAGS += -march=i686
     CFG_GCCISH_LINK_FLAGS += -shared -fPIC
   endif
 
@@ -141,7 +148,7 @@ CFG_INFO := $(info cfg: using $(CFG_C_COMPILER))
 ifeq ($(CFG_C_COMPILER),clang)
   CC=clang
   CXX=clang++
-  CFG_GCCISH_CFLAGS += -Wall -Werror -fno-rtti -fno-exceptions -g
+  CFG_GCCISH_CFLAGS += -Wall -Werror -fno-rtti -g
   CFG_GCCISH_LINK_FLAGS += -g
   CFG_COMPILE_C = $(CFG_GCCISH_CROSS)$(CXX) $(CFG_GCCISH_CFLAGS) \
     $(CFG_CLANG_CFLAGS) -c -o $(1) $(2)
@@ -153,7 +160,7 @@ else
 ifeq ($(CFG_C_COMPILER),gcc)
   CC=gcc
   CXX=g++
-  CFG_GCCISH_CFLAGS += -Wall -Werror -fno-rtti -fno-exceptions -g
+  CFG_GCCISH_CFLAGS += -Wall -Werror -fno-rtti -g
   CFG_GCCISH_LINK_FLAGS += -g
   CFG_COMPILE_C = $(CFG_GCCISH_CROSS)$(CXX) $(CFG_GCCISH_CFLAGS) \
     $(CFG_GCC_CFLAGS) -c -o $(1) $(2)

trunk/mk/pp.mk

@@ -9,7 +9,7 @@ else
               $(wildcard $(S)src/fuzzer/*.rs)
 
   PP_INPUTS_FILTERED = $(shell echo $(PP_INPUTS) | xargs grep -L \
-                       "no-reformat\|xfail-pretty\|xfail-stage2")
+                       "no-reformat\|xfail-pretty\|xfail-test")
 endif
 
 reformat: $(SREQ1)