---

yaml
---
r: 95307
b: refs/heads/dist-snap
c: 8fcf62b
h: refs/heads/master
i:
  95305: 984ef1f
  95303: 923cc2d
v: v3

Author: alexcrichton

[refs]

@@ -6,7 +6,7 @@ refs/heads/try: c274a6888410ce3e357e014568b43310ed787d36
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c
-refs/heads/dist-snap: 62812f1e38f438dfc666cd9d164b4377063f8794
+refs/heads/dist-snap: 8fcf62b6385a5be4ef3a8e1bdb0f01ce907abd26
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/heads/try3: 9387340aab40a73e8424c48fd42f0c521a4875c0

branches/dist-snap/Makefile.in

@@ -147,17 +147,11 @@ CFG_VERSION = $(CFG_RELEASE)
 # numbers and dots here
 CFG_VERSION_WIN = 0.9
 
-# since $(CFG_GIT) may contain spaces (especially on Windows),
-# we need to escape them. (" " to r"\ ")
-# Note that $(subst ...) ignores space after `subst`,
-# so we use a hack: define $(SPACE) which contains space character.
-SPACE :=
-SPACE +=
-ifneq ($(wildcard $(subst $(SPACE),\$(SPACE),$(CFG_GIT))),)
-ifneq ($(wildcard $(subst $(SPACE),\$(SPACE),$(CFG_GIT_DIR))),)
-    CFG_VERSION += $(shell git --git-dir='$(CFG_GIT_DIR)' log -1 \
+ifneq ($(wildcard $(CFG_GIT)),)
+ifneq ($(wildcard $(CFG_GIT_DIR)),)
+    CFG_VERSION += $(shell git --git-dir=$(CFG_GIT_DIR) log -1 \
                      --pretty=format:'(%h %ci)')
-    CFG_VER_HASH = $(shell git --git-dir='$(CFG_GIT_DIR)' rev-parse HEAD)
+    CFG_VER_HASH = $(shell git --git-dir=$(CFG_GIT_DIR) rev-parse HEAD)
 endif
 endif
 

branches/dist-snap/configure

@@ -680,15 +680,11 @@ do
   for s in 0 1 2 3
   do
     make_dir $t/rt/stage$s
-    make_dir $t/rt/libuv
-    make_dir $t/rt/libuv/src/ares
-    make_dir $t/rt/libuv/src/eio
-    make_dir $t/rt/libuv/src/ev
-    make_dir $t/rt/jemalloc
     for i in                                          \
       isaac linenoise sync test \
       arch/i386 arch/x86_64 arch/arm arch/mips  \
-      sundown/src sundown/html
+      libuv libuv/src/ares libuv/src/eio libuv/src/ev \
+      jemalloc sundown/src sundown/html
     do
       make_dir $t/rt/stage$s/$i
     done

branches/dist-snap/doc/rust.md

@@ -239,14 +239,13 @@ literal : string_lit | char_lit | num_lit ;
 
 ~~~~~~~~ {.ebnf .gram}
 char_lit : '\x27' char_body '\x27' ;
-string_lit : '"' string_body * '"' | 'r' raw_string ;
+string_lit : '"' string_body * '"' ;
 
 char_body : non_single_quote
           | '\x5c' [ '\x27' | common_escape ] ;
 
 string_body : non_double_quote
             | '\x5c' [ '\x22' | common_escape ] ;
-raw_string : '"' raw_string_body '"' | '#' raw_string '#' ;
 
 common_escape : '\x5c'
               | 'n' | 'r' | 't' | '0'
@@ -268,10 +267,9 @@ which must be _escaped_ by a preceding U+005C character (`\`).
 
 A _string literal_ is a sequence of any Unicode characters enclosed within
 two `U+0022` (double-quote) characters, with the exception of `U+0022`
-itself, which must be _escaped_ by a preceding `U+005C` character (`\`),
-or a _raw string literal_.
+itself, which must be _escaped_ by a preceding `U+005C` character (`\`).
 
-Some additional _escapes_ are available in either character or non-raw string
+Some additional _escapes_ are available in either character or string
 literals. An escape starts with a `U+005C` (`\`) and continues with one of
 the following forms:
 
@@ -287,35 +285,9 @@ the following forms:
   * A _whitespace escape_ is one of the characters `U+006E` (`n`), `U+0072`
     (`r`), or `U+0074` (`t`), denoting the unicode values `U+000A` (LF),
     `U+000D` (CR) or `U+0009` (HT) respectively.
-  * The _backslash escape_ is the character `U+005C` (`\`) which must be
+  * The _backslash escape_ is the character U+005C (`\`) which must be
     escaped in order to denote *itself*.
 
-Raw string literals do not process any escapes. They start with the character
-`U+0072` (`r`), followed zero or more of the character `U+0023` (`#`) and a
-`U+0022` (double-quote) character. The _raw string body_ is not defined in the
-EBNF grammar above: it can contain any sequence of Unicode characters and is
-terminated only by another `U+0022` (double-quote) character, followed by the
-same number of `U+0023` (`#`) characters that preceeded the opening `U+0022`
-(double-quote) character.
-
-All Unicode characters contained in the raw string body represent themselves,
-the characters `U+0022` (double-quote) (except when followed by at least as
-many `U+0023` (`#`) characters as were used to start the raw string literal) or
-`U+005C` (`\`) do not have any special meaning.
-
-Examples for string literals:
-
-~~~
-"foo"; r"foo";                     // foo
-"\"foo\""; r#""foo""#;             // "foo"
-
-"foo #\"# bar";
-r##"foo #"# bar"##;                // foo #"# bar
-
-"\x52"; "R"; r"R";                 // R
-"\\x52"; r"\x52";                  // \x52
-~~~
-
 #### Number literals
 
 ~~~~~~~~ {.ebnf .gram}
@@ -1529,171 +1501,6 @@ is `extern "abi" fn(A1, ..., An) -> R`,
 where `A1...An` are the declared types of its arguments
 and `R` is the decalred return type.
 
-## Visibility and Privacy
-
-These two terms are often used interchangeably, and what they are attempting to
-convey is the answer to the question "Can this item be used at this location?"
-
-Rust's name resolution operates on a global hierarchy of namespaces. Each level
-in the hierarchy can be thought of as some item. The items are one of those
-mentioned above, but also include external crates. Declaring or defining a new
-module can be thought of as inserting a new tree into the hierarchy at the
-location of the definition.
-
-To control whether interfaces can be used across modules, Rust checks each use
-of an item to see whether it should be allowed or not. This is where privacy
-warnings are generated, or otherwise "you used a private item of another module
-and weren't allowed to."
-
-By default, everything in rust is *private*, with two exceptions. The first
-exception is that struct fields are public by default (but the struct itself is
-still private by default), and the remaining exception is that enum variants in
-a `pub` enum are the default visibility of the enum container itself.. You are
-allowed to alter this default visibility with the `pub` keyword (or `priv`
-keyword for struct fields and enum variants). When an item is declared as `pub`,
-it can be thought of as being accessible to the outside world. For example:
-
-~~~
-// Declare a private struct
-struct Foo;
-
-// Declare a public struct with a private field
-pub struct Bar {
-    priv field: int
-}
-
-// Declare a public enum with public and private variants
-pub enum State {
-    PubliclyAccessibleState,
-    priv PrivatelyAccessibleState
-}
-~~~
-
-With the notion of an item being either public or private, Rust allows item
-accesses in two cases:
-
-1. If an item is public, then it can be used externally through any of its
-   public ancestors.
-2. If an item is private, it may be accessed by the current module and its
-   descendants.
-
-These two cases are surprisingly powerful for creating module hierarchies
-exposing public APIs while hiding internal implementation details. To help
-explain, here's a few use cases and what they would entail.
-
-* A library developer needs to expose functionality to crates which link against
-  their library. As a consequence of the first case, this means that anything
-  which is usable externally must be `pub` from the root down to the destination
-  item. Any private item in the chain will disallow external accesses.
-
-* A crate needs a global available "helper module" to itself, but it doesn't
-  want to expose the helper module as a public API. To accomplish this, the root
-  of the crate's hierarchy would have a private module which then internally has
-  a "public api". Because the entire crate is an ancestor of the root, then the
-  entire local crate can access this private module through the second case.
-
-* When writing unit tests for a module, it's often a common idiom to have an
-  immediate child of the module to-be-tested named `mod test`. This module could
-  access any items of the parent module through the second case, meaning that
-  internal implementation details could also be seamlessly tested from the child
-  module.
-
-In the second case, it mentions that a private item "can be accessed" by the
-current module and its descendants, but the exact meaning of accessing an item
-depends on what the item is. Accessing a module, for example, would mean looking
-inside of it (to import more items). On the other hand, accessing a function
-would mean that it is invoked.
-
-Here's an example of a program which exemplifies the three cases outlined above.
-
-~~~
-// This module is private, meaning that no external crate can access this
-// module. Because it is private at the root of this current crate, however, any
-// module in the crate may access any publicly visible item in this module.
-mod crate_helper_module {
-
-    // This function can be used by anything in the current crate
-    pub fn crate_helper() {}
-
-    // This function *cannot* be used by anything else in the crate. It is not
-    // publicly visible outside of the `crate_helper_module`, so only this
-    // current module and its descendants may access it.
-    fn implementation_detail() {}
-}
-
-// This function is "public to the root" meaning that it's available to external
-// crates linking against this one.
-pub fn public_api() {}
-
-// Similarly to 'public_api', this module is public so external crates may look
-// inside of it.
-pub mod submodule {
-    use crate_helper_module;
-
-    pub fn my_method() {
-        // Any item in the local crate may invoke the helper module's public
-        // interface through a combination of the two rules above.
-        crate_helper_module::crate_helper();
-    }
-
-    // This function is hidden to any module which is not a descendant of
-    // `submodule`
-    fn my_implementation() {}
-
-    #[cfg(test)]
-    mod test {
-
-        #[test]
-        fn test_my_implementation() {
-            // Because this module is a descendant of `submodule`, it's allowed
-            // to access private items inside of `submodule` without a privacy
-            // violation.
-            super::my_implementation();
-        }
-    }
-}
-
-# fn main() {}
-~~~
-
-For a rust program to pass the privacy checking pass, all paths must be valid
-accesses given the two rules above. This includes all use statements,
-expressions, types, etc.
-
-### Re-exporting and Visibility
-
-Rust allows publicly re-exporting items through a `pub use` directive. Because
-this is a public directive, this allows the item to be used in the current
-module through the rules above. It essentially allows public access into the
-re-exported item. For example, this program is valid:
-
-~~~
-pub use api = self::implementation;
-
-mod implementation {
-    pub fn f() {}
-}
-
-# fn main() {}
-~~~
-
-This means that any external crate referencing `implementation::f` would receive
-a privacy violation, while the path `api::f` would be allowed.
-
-When re-exporting a private item, it can be thought of as allowing the "privacy
-chain" being short-circuited through the reexport instead of passing through the
-namespace hierarchy as it normally would.
-
-### Glob imports and Visibility
-
-Currently glob imports are considered an "experimental" language feature. For
-sanity purpose along with helping the implementation, glob imports will only
-import public items from their destination, not private items.
-
-> **Note:** This is subject to change, glob exports may be removed entirely or
-> they could possibly import private items for a privacy error to later be
-> issued if the item is used.
-
 ## Attributes
 
 ~~~~~~~~{.ebnf .gram}
@@ -2026,58 +1833,6 @@ fn main() {
 > individual functions, structs, methods and enum variants, *not* to
 > entire modules, traits, impls or enums themselves.
 
-### Compiler Features
-
-Certain aspects of Rust may be implemented in the compiler, but they're not
-necessarily ready for every-day use. These features are often of "prototype
-quality" or "almost production ready", but may not be stable enough to be
-considered a full-fleged language feature.
-
-For this reason, rust recognizes a special crate-level attribute of the form:
-
-~~~ {.xfail-test}
-#[feature(feature1, feature2, feature3)]
-~~~
-
-This directive informs the compiler that the feature list: `feature1`,
-`feature2`, and `feature3` should all be enabled. This is only recognized at a
-crate-level, not at a module-level. Without this directive, all features are
-considered off, and using the features will result in a compiler error.
-
-The currently implemented features of the compiler are:
-
-* `macro_rules` - The definition of new macros. This does not encompass
-                  macro-invocation, that is always enabled by default, this only
-                  covers the definition of new macros. There are currently
-                  various problems with invoking macros, how they interact with
-                  their environment, and possibly how they are used outside of
-                  location in which they are defined. Macro definitions are
-                  likely to change slightly in the future, so they are currently
-                  hidden behind this feature.
-
-* `globs` - Importing everything in a module through `*`. This is currently a
-            large source of bugs in name resolution for Rust, and it's not clear
-            whether this will continue as a feature or not. For these reasons,
-            the glob import statement has been hidden behind this feature flag.
-
-* `struct_variant` - Structural enum variants (those with named fields). It is
-                     currently unknown whether this style of enum variant is as
-                     fully supported as the tuple-forms, and it's not certain
-                     that this style of variant should remain in the language.
-                     For now this style of variant is hidden behind a feature
-                     flag.
-
-If a feature is promoted to a language feature, then all existing programs will
-start to receive compilation warnings about #[feature] directives which enabled
-the new feature (because the directive is no longer necessary). However, if
-a feature is decided to be removed from the language, errors will be issued (if
-there isn't a parser error first). The directive in this case is no longer
-necessary, and it's likely that existing code will break if the feature isn't
-removed.
-
-If a unknown feature is found in a directive, it results in a compiler error. An
-unknown feature is one which has never been recognized by the compiler.
-
 # Statements and expressions
 
 Rust is _primarily_ an expression language. This means that most forms of