1. 23 5月, 2014 1 次提交
  2. 19 5月, 2014 1 次提交
    • F
      Fixing rustdoc stage1. · eb6856c3
      Felix S. Klock II 提交于
      See #13983 and #14000.
      
      Fix was originally authored by alexcrichton and then rebased a couple
      times by pnkfelix, most recently atop PR 13954.
      
      ----
      
      Regarding the change to librustdoc/lib.rs, to do `map_err` before
      unwrapping a `TqskResult`: I do not understand how master is passing
      without this change or something like it, since `Box<Any:Send>` does
      not implement `Show`.  (Is this something that is only a problem for
      the snapshot stage0 compiler?)  Still, the change I have put in here
      (which was added as part of a rebase after alex's review) seems
      harmless to me to apply to rustdoc at all stages, since a call to
      `unwrap` is just going to `fail!` on the err case anyway.
      eb6856c3
  3. 17 5月, 2014 2 次提交
  4. 15 5月, 2014 1 次提交
  5. 13 5月, 2014 2 次提交
  6. 11 5月, 2014 1 次提交
    • N
      Reorganise driver code. · 37ca3678
      Nick Cameron 提交于
      The goal of this refactoring is to make the rustc driver code easier to understand and use. Since this is as close to an API as we have, I think it is important that it is nice. On getting stuck in, I found that there wasn't as much to change as I'd hoped to make the stage... fns easier to use by tools.
      
      This patch only moves code around - mostly just moving code to different files, but a few extracted method refactorings too. To summarise the changes: I added driver::config which handles everything about configuring the compiler. driver::session now just defines and builds session objects. I moved driver code from librustc/lib.rs to librustc/driver/mod.rs so all the code is one place. I extracted methods to make emulating the compiler without being the compiler a little easier. Within the driver directory, I moved code around to more logically fit in the modules.
      37ca3678
  7. 09 5月, 2014 1 次提交
  8. 08 5月, 2014 1 次提交
    • A
      std: Modernize the local_data api · ab92ea52
      Alex Crichton 提交于
      This commit brings the local_data api up to modern rust standards with a few key
      improvements:
      
      * The `pop` and `set` methods have been combined into one method, `replace`
      
      * The `get_mut` method has been removed. All interior mutability should be done
        through `RefCell`.
      
      * All functionality is now exposed as a method on the keys themselves. Instead
        of importing std::local_data, you now use "key.replace()" and "key.get()".
      
      * All closures have been removed in favor of RAII functionality. This means that
        get() and get_mut() no long require closures, but rather return
        Option<SmartPointer> where the smart pointer takes care of relinquishing the
        borrow and also implements the necessary Deref traits
      
      * The modify() function was removed to cut the local_data interface down to its
        bare essentials (similarly to how RefCell removed set/get).
      
      [breaking-change]
      ab92ea52
  9. 03 5月, 2014 1 次提交
  10. 29 4月, 2014 1 次提交
    • J
      Deprecate the rev_iter pattern in all places where a DoubleEndedIterator is... · 03609e5a
      Jonathan S 提交于
      Deprecate the rev_iter pattern in all places where a DoubleEndedIterator is provided (everywhere but treemap)
      
      This commit deprecates rev_iter, mut_rev_iter, move_rev_iter everywhere (except treemap) and also
      deprecates related functions like rsplit, rev_components, and rev_str_components. In every case,
      these functions can be replaced with the non-reversed form followed by a call to .rev(). To make this
      more concrete, a translation table for all functional changes necessary follows:
      
      * container.rev_iter() -> container.iter().rev()
      * container.mut_rev_iter() -> container.mut_iter().rev()
      * container.move_rev_iter() -> container.move_iter().rev()
      * sliceorstr.rsplit(sep) -> sliceorstr.split(sep).rev()
      * path.rev_components() -> path.components().rev()
      * path.rev_str_components() -> path.str_components().rev()
      
      In terms of the type system, this change also deprecates any specialized reversed iterator types (except
      in treemap), opting instead to use Rev directly if any type annotations are needed. However, since
      methods directly returning reversed iterators are now discouraged, the need for such annotations should
      be small. However, in those cases, the general pattern for conversion is to take whatever follows Rev in
      the original reversed name and surround it with Rev<>:
      
      * RevComponents<'a> -> Rev<Components<'a>>
      * RevStrComponents<'a> -> Rev<StrComponents<'a>>
      * RevItems<'a, T> -> Rev<Items<'a, T>>
      * etc.
      
      The reasoning behind this change is that it makes the standard API much simpler without reducing readability,
      performance, or power. The presence of functions such as rev_iter adds more boilerplate code to libraries
      (all of which simply call .iter().rev()), clutters up the documentation, and only helps code by saving two
      characters. Additionally, the numerous type synonyms that were used to make the type signatures look nice
      like RevItems add even more boilerplate and clutter up the docs even more. With this change, all that cruft
      goes away.
      
      [breaking-change]
      03609e5a
  11. 26 4月, 2014 1 次提交
  12. 19 4月, 2014 1 次提交
  13. 14 4月, 2014 1 次提交
  14. 07 4月, 2014 1 次提交
  15. 05 4月, 2014 1 次提交
  16. 04 4月, 2014 2 次提交
    • B
      Bump version to 0.11-pre · 0875ffcb
      Brian Anderson 提交于
      This also changes some of the download links in the documentation
      to 'nightly'.
      0875ffcb
    • A
      std: Document builtin syntax extensions · 78937b97
      Alex Crichton 提交于
      These syntax extensions need a place to be documented, and this starts passing a
      `--cfg dox` parameter to `rustdoc` when building and testing documentation in
      order to document macros so that they have no effect on the compiled crate, but
      only documentation.
      
      Closes #5605
      78937b97
  17. 01 4月, 2014 1 次提交
  18. 29 3月, 2014 2 次提交
  19. 28 3月, 2014 1 次提交
    • S
      serialize: use Result · f1739b14
      Sean McArthur 提交于
      All of Decoder and Encoder's methods now return a Result.
      
      Encodable.encode() and Decodable.decode() return a Result as well.
      
      fixes #12292
      f1739b14
  20. 21 3月, 2014 2 次提交
  21. 19 3月, 2014 1 次提交
    • A
      rustdoc: Implement cross-crate searching · 848f7b73
      Alex Crichton 提交于
      A major discoverability issue with rustdoc is that all crates have their
      documentation built in isolation, so it's difficult when looking at the
      documentation for libstd to learn that there's a libcollections crate with a
      HashMap in it.
      
      This commit moves rustdoc a little closer to improving the multiple crate
      experience. This unifies all search indexes for all crates into one file so all
      pages share the same search index. This allows searching to work across crates
      in the same documentation directory (as the standard distribution is currently
      built).
      
      This strategy involves updating a shared file amongst many rustdoc processes, so
      I implemented a simple file locking API for handling synchronization for updates
      to the shared files.
      
      cc #12554
      848f7b73
  22. 17 3月, 2014 2 次提交
  23. 16 3月, 2014 1 次提交
    • A
      log: Introduce liblog, the old std::logging · cc6ec8df
      Alex Crichton 提交于
      This commit moves all logging out of the standard library into an external
      crate. This crate is the new crate which is responsible for all logging macros
      and logging implementation. A few reasons for this change are:
      
      * The crate map has always been a bit of a code smell among rust programs. It
        has difficulty being loaded on almost all platforms, and it's used almost
        exclusively for logging and only logging. Removing the crate map is one of the
        end goals of this movement.
      
      * The compiler has a fair bit of special support for logging. It has the
        __log_level() expression as well as generating a global word per module
        specifying the log level. This is unfairly favoring the built-in logging
        system, and is much better done purely in libraries instead of the compiler
        itself.
      
      * Initialization of logging is much easier to do if there is no reliance on a
        magical crate map being available to set module log levels.
      
      * If the logging library can be written outside of the standard library, there's
        no reason that it shouldn't be. It's likely that we're not going to build the
        highest quality logging library of all time, so third-party libraries should
        be able to provide just as high-quality logging systems as the default one
        provided in the rust distribution.
      
      With a migration such as this, the change does not come for free. There are some
      subtle changes in the behavior of liblog vs the previous logging macros:
      
      * The core change of this migration is that there is no longer a physical
        log-level per module. This concept is still emulated (it is quite useful), but
        there is now only a global log level, not a local one. This global log level
        is a reflection of the maximum of all log levels specified. The previously
        generated logging code looked like:
      
          if specified_level <= __module_log_level() {
              println!(...)
          }
      
        The newly generated code looks like:
      
          if specified_level <= ::log::LOG_LEVEL {
              if ::log::module_enabled(module_path!()) {
                  println!(...)
              }
          }
      
        Notably, the first layer of checking is still intended to be "super fast" in
        that it's just a load of a global word and a compare. The second layer of
        checking is executed to determine if the current module does indeed have
        logging turned on.
      
        This means that if any module has a debug log level turned on, all modules
        with debug log levels get a little bit slower (they all do more expensive
        dynamic checks to determine if they're turned on or not).
      
        Semantically, this migration brings no change in this respect, but
        runtime-wise, this will have a perf impact on some code.
      
      * A `RUST_LOG=::help` directive will no longer print out a list of all modules
        that can be logged. This is because the crate map will no longer specify the
        log levels of all modules, so the list of modules is not known. Additionally,
        warnings can no longer be provided if a malformed logging directive was
        supplied.
      
      The new "hello world" for logging looks like:
      
          #[phase(syntax, link)]
          extern crate log;
      
          fn main() {
              debug!("Hello, world!");
          }
      cc6ec8df
  24. 15 3月, 2014 1 次提交
    • A
      extra: Put the nail in the coffin, delete libextra · 58e4ab2b
      Alex Crichton 提交于
      This commit shreds all remnants of libextra from the compiler and standard
      distribution. Two modules, c_vec/tempfile, were moved into libstd after some
      cleanup, and the other modules were moved to separate crates as seen fit.
      
      Closes #8784
      Closes #12413
      Closes #12576
      58e4ab2b
  25. 14 3月, 2014 1 次提交
    • H
      lint: add lint for use of a `~[T]`. · 62792f09
      Huon Wilson 提交于
      This is useless at the moment (since pretty much every crate uses
      `~[]`), but should help avoid regressions once completely removed from a
      crate.
      62792f09
  26. 13 3月, 2014 1 次提交
    • M
      rustc: Remove matching on ~str from the language · f079c94f
      Michael Darakananda 提交于
      The `~str` type is not long for this world as it will be superseded by the
      soon-to-come DST changes for the language. The new type will be
      `~Str`, and matching over the allocation will no longer be supported.
      Matching on `&str` will continue to work, in both a pre and post DST world.
      f079c94f
  27. 09 3月, 2014 2 次提交
    • H
      rustdoc: add table-of-contents recording & rendering, use it with plain · f22c96cc
      Huon Wilson 提交于
      markdown files.
      
      This means that
      
          # Foo
          ## Bar
          # Baz
          ### Qux
          ## Quz
      
      Gets a TOC like
      
          1 Foo
             1.1 Bar
          2 Baz
             2.0.1 Qux
             2.1 Quz
      
      This functionality is only used when rendering a single markdown file,
      never on an individual module, although it could very feasibly be
      extended to allow modules to opt-in to a table of contents (std::fmt
      comes to mind).
      f22c96cc
    • H
      rustdoc: run on plain Markdown files. · 69b8ef80
      Huon Wilson 提交于
      This theoretically gives rustdoc the ability to render our guides,
      tutorial and manual (not in practice, since the files themselves need to
      be adjusted slightly to use Sundown-compatible functionality).
      
      Fixes #11392.
      69b8ef80
  28. 25 2月, 2014 1 次提交
  29. 24 2月, 2014 1 次提交
  30. 23 2月, 2014 1 次提交
    • A
      rustdoc: Add syntax highlighting · ad9e26da
      Alex Crichton 提交于
      This adds simple syntax highlighting based off libsyntax's lexer to be sure to
      stay up to date with rust's grammar. Some of the highlighting is a bit ad-hoc,
      but it definitely seems to get the job done!
      
      This currently doesn't highlight rustdoc-rendered function signatures and
      structs that are emitted to each page because the colors already signify what's
      clickable and I think we'd have to figure out a different scheme before
      colorizing them. This does, however, colorize all code examples and source code.
      
      Closes #11393
      ad9e26da
  31. 21 2月, 2014 2 次提交
    • A
      Move time out of extra (cc #8784) · 66f93291
      Arcterus 提交于
      66f93291
    • A
      Mass rename if_ok! to try! · 7bb498bd
      Alex Crichton 提交于
      This "bubble up an error" macro was originally named if_ok! in order to get it
      landed, but after the fact it was discovered that this name is not exactly
      desirable.
      
      The name `if_ok!` isn't immediately clear that is has much to do with error
      handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
      general, the agreed opinion about `if_ok!` is that is came in as subpar.
      
      The name `try!` is more invocative of error handling, it's shorter by 2 letters,
      and it looks fitting in almost all circumstances. One concern about the word
      `try!` is that it's too invocative of exceptions, but the belief is that this
      will be overcome with documentation and examples.
      
      Close #12037
      7bb498bd
  32. 20 2月, 2014 1 次提交