- 17 3月, 2014 25 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 bors 提交于
-
由 bors 提交于
-
由 bors 提交于
its a common (yet easily fixable) error to just forget parens at the end of getter-like methods without any arguments. The current error message for that case asks for an anonymous function, this patch adds a note asking for either an anonymous function, or for trailing parens. This is my first contribution! do i need to do anything else?
-
由 Matthew McPherrin 提交于
-
由 Cadence Marseille 提交于
-
由 bors 提交于
Using pattern matching instead of is_some + unwrap
-
由 Alan Andrade 提交于
-
由 Davis Silverman 提交于
-
由 bors 提交于
The same test was missed in chan/port renaming PR #12815 and was fixed in #12880: > This was missed because it is skipped on linux and windows, and the mac bots were moving at the time the PR landed. It seems the same happened to the liblog PR.
-
- 16 3月, 2014 15 次提交
-
-
由 Edward Wang 提交于
-
由 bors 提交于
This is a minor optimization of the bignum module. The improvements mostly come from avoiding allocations and boundary checks. This also switches all of libnum to vec_ng::Vec.
-
由 aochagavia 提交于
Using pattern matching instead of is_some + unwrap
-
由 bors 提交于
This will enable rustdoc to treat them specially. I also got rid of `std::cmp::cmp2`, which is isomorphic to the `TotalOrd` impl for 2-tuples and never used.
-
由 bors 提交于
After `make clean` I'm seeing the build break with ``` cp: cannot stat ‘x86_64-unknown-linux-gnu/rt/libbacktrace/.libs/libbacktrace.a’: No such file or directory ``` Deleteing the libbacktrace dir entirely on clean fixes.
-
由 bors 提交于
The rationale and modifications can be found in the first commit message. This does make logging a bit more painful to use initially because it involves a feature gate and some `phase` attributes, but I think it may be reasonable to not require the `phase` attribute for loading `macro_rules!` macros because defining them will still be gated.
-
由 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).
-
由 Steven Fackler 提交于
This will enable rustdoc to treat them specially.
-
由 Alex Crichton 提交于
This commit starts to topographically sort rust dependencies on the linker command line. The reason for this is that linkers use right-hand libraries to resolve left-hand libraries symbols, which is especially crucial for us because we're using --as-needed on linux.
-
由 Alex Crichton 提交于
In removing many fields from the crate map, executables no longer always have an explicit dependency on all upstream libraries. This means that the linker is no longer picking them up as it used to. To the best of my knowledge, the current situation is happening: * On linux, we're passing the --as-needed flag to the linker, meaning that libraries are stripped out if there are no references to symbols in them. * Executables may not reference libstd at all, such as "fn main() {}" * When linking, the linker will discard libstd because there are no references to symbols in it. I presume that this means that all previous libs have had all their symbols resolved, so none of the libs are pulling in libstd as a dependency. * The only real dependence on libstd comes from the rust_stack_exhausted symbol (which comes from libmorestack), but -lmorestack is at the end so by the time this comes up libstd is completely gone, leading to undefined references to rust_stack_exhausted I'm not entirely convinced that this is what's happening, but it appears to be along these lines. The one thing that I'm sure of is that removing the crate map (and hence implicit dependency on all upstream libraries) has changed how objects depend on upstream libraries.
-
由 Alex Crichton 提交于
This commit removes all internal support for the previously used __log_level() expression. The logging subsystem was previously modified to not rely on this magical expression. This also removes the only other function to use the module_data map in trans, decl_gc_metadata. It appears that this is an ancient function from a GC only used long ago. This does not remove the crate map entirely, as libgreen still uses it to hook in to the event loop provided by libgreen.
-
由 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!"); }
-
由 bors 提交于
The use of `std::os::args` creates a deprecated_owned_vector warning with a bogus span.
-
由 Steven Fackler 提交于
It isn't used anywhere and `cmp2(a, b, c, d)` is identical to `(a, b).cmp(&(c, d))`.
-
由 Steven Fackler 提交于
The use of `std::os::args` creates a deprecated_owned_vector warning with a bogus span.
-