1. 31 12月, 2020 1 次提交
  2. 27 7月, 2019 2 次提交
  3. 26 12月, 2018 1 次提交
  4. 21 9月, 2018 1 次提交
  5. 30 1月, 2015 1 次提交
  6. 12 11月, 2014 1 次提交
  7. 29 10月, 2014 1 次提交
    • S
      Rename fail! to panic! · 7828c3dd
      Steve Klabnik 提交于
      https://github.com/rust-lang/rfcs/pull/221
      
      The current terminology of "task failure" often causes problems when
      writing or speaking about code. You often want to talk about the
      possibility of an operation that returns a Result "failing", but cannot
      because of the ambiguity with task failure. Instead, you have to speak
      of "the failing case" or "when the operation does not succeed" or other
      circumlocutions.
      
      Likewise, we use a "Failure" header in rustdoc to describe when
      operations may fail the task, but it would often be helpful to separate
      out a section describing the "Err-producing" case.
      
      We have been steadily moving away from task failure and toward Result as
      an error-handling mechanism, so we should optimize our terminology
      accordingly: Result-producing functions should be easy to describe.
      
      To update your code, rename any call to `fail!` to `panic!` instead.
      Assuming you have not created your own macro named `panic!`, this
      will work on UNIX based systems:
      
          grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
      
      You can of course also do this by hand.
      
      [breaking-change]
      7828c3dd
  8. 17 10月, 2014 2 次提交
  9. 14 4月, 2014 1 次提交
  10. 16 3月, 2014 2 次提交
    • A
      Test fixes and rebase conflicts · 0015cab1
      Alex Crichton 提交于
      This commit switches over the backtrace infrastructure from piggy-backing off
      the RUST_LOG environment variable to using the RUST_BACKTRACE environment
      variable (logging is now disabled in libstd).
      0015cab1
    • 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
  11. 26 10月, 2013 1 次提交
  12. 22 10月, 2013 1 次提交
  13. 01 10月, 2013 1 次提交
  14. 17 8月, 2013 1 次提交
  15. 17 7月, 2013 1 次提交
  16. 12 3月, 2013 1 次提交
  17. 14 2月, 2013 1 次提交
  18. 02 2月, 2013 1 次提交
  19. 01 2月, 2013 1 次提交
  20. 11 12月, 2012 1 次提交
  21. 23 12月, 2011 2 次提交
  22. 21 8月, 2011 1 次提交
    • B
      Reformat · 518dc52f
      Brian Anderson 提交于
      This changes the indexing syntax from .() to [], the vector syntax from ~[] to
      [] and the extension syntax from #fmt() to #fmt[]
      518dc52f
  23. 16 6月, 2011 1 次提交
  24. 17 5月, 2011 1 次提交