| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This will enable rustdoc to treat them specially.
|
|
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.
|
|
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!");
}
|
|
## read+write modifier '+'
This small sugar was left out in the original implementation (#5359).
When an output operand with the '+' modifier is encountered, we store the index of that operand alongside the expression to create and append an input operand later. The following lines are equivalent:
```
asm!("" : "+m"(expr));
asm!("" : "=m"(expr) : "0"(expr));
```
## misplaced options and clobbers give a warning
It's really annoying when a small typo might change behavior without any warning.
```
asm!("mov $1, $0" : "=r"(x) : "r"(8u) : "cc" , "volatile");
//~^ WARNING expected a clobber, but found an option
```
## liveness
Fixed incorrect order of propagation.
Sometimes it caused spurious warnings in code: `warning: value assigned to `i` is never read, #[warn(dead_assignment)] on by default`
~~Note: Rebased on top of another PR. (uses other changes)~~
* [x] Implement read+write
* [x] Warn about misplaced options
* [x] Fix liveness (`dead_assignment` lint)
* [x] Add all tests
|
|
Read+write modifier
Some documentation in asm.rs
rpass and cfail tests
|
|
Rc<RefCell<T>>.
|
|
|
|
There is a broader revision (that does this across the board) pending
in #12675, but that is awaiting the arrival of more data (to decide
whether to keep OptVec alive by using a non-Vec internally).
For this code, the representation of lifetime lists needs to be the
same in both ScopeChain and in the ast and ty structures. So it
seemed cleanest to just use `vec_ng::Vec`, now that it has a cheaper
empty representation than the current `vec` code.
|
|
|
|
|
|
This functionality is not super-core and so doesn't need to be included
in std. It's possible that std may need rand (it does a little bit now,
for io::test) in which case the functionality required could be moved to
a secret hidden module and reexposed by librand.
Unfortunately, using #[deprecated] here is hard: there's too much to
mock to make it feasible, since we have to ensure that programs still
typecheck to reach the linting phase.
|
|
Where ItemDecorator creates new items given a single item, ItemModifier
alters the tagged item in place. The expansion rules for this are a bit
weird, but I think are the most reasonable option available.
When an item is expanded, all ItemModifier attributes are stripped from
it and the item is folded through all ItemModifiers. At that point, the
process repeats until there are no ItemModifiers in the new item.
|
|
|
|
clean::ExternMod to clean::ExternCrate
|
|
If #[feature(default_type_parameters)] is enabled for a crate, then
deriving(Hash) will expand with Hash<W: Writer> instead of Hash<SipState> so
more hash algorithms can be used.
|
|
- Moves mtwt hygiene code into its own file
- Fixes FIXME's which leads to ~2x speed gain in expansion pass
- It is now @-free
|
|
Fixes a regression from #4913 which causes items to be exanded with spans lacking expn_info from the context's current backtrace.
|
|
Previously `ast::Arm` was always storing a single `ast::Expr` wrapped in an
`ast::Block` (for historical reasons, AIUI), so we might as just store
that expr directly.
Closes #3085.
|
|
|
|
|
|
A couple of syntax extensions manually expanded expressions, but it
wasn't done universally, most noticably inside of asm!().
There's also a bit of random cleanup.
|
|
|
|
|
|
Previously, format!("{a}{b}", a=foo(), b=bar()) has foo() and bar() run in a
nondeterminisc order. This is clearly a non-desirable property, so this commit
uses iteration over a list instead of iteration over a hash map to provide
deterministic code generation of these format arguments.
|
|
The most significant fix is for `syntax::ext::deriving::encodable`,
where one of the blocks of code, auspiciously containing `<S>` (recall
that Markdown allows arbitrary HTML to be contained inside it), was not
formatted as a code block, with a fun but messy effect.
|
|
|
|
Fixes #12423.
|
|
This has been superseded by deriving(Show).
cc #9806
|
|
This includes blocks made by indentation, so they need to be changed to
explicitly have ```notrust ... ``` fences..
|
|
This includes blocks made by indentation, so they need to be changed to
explicitly have ```notrust ... ``` fences..
|
|
Makes labelled loops hygiene by performing renaming of the labels defined in e.g. `'x: loop { ... }` and then used in break and continue statements within loop body so that they act hygienically when used with macros.
Closes #12262.
|
|
|
|
Makes labelled loops hygiene by performing renaming of the labels
defined in e.g. `'x: loop { ... }` and then used in break and continue
statements within loop body so that they act hygienically when used with
macros.
Closes #12262.
|
|
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.
This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
|
|
Closes #7743.
|
|
This patch merges IterBytes and Hash traits, which clears up the
confusion of using `#[deriving(IterBytes)]` to support hashing.
Instead, it now is much easier to use the new `#[deriving(Hash)]`
for making a type hashable with a stream hash.
Furthermore, it supports custom non-stream-based hashers, such as
if a value's hash was cached in a database.
This does not yet replace the old IterBytes-hash with this new
version.
|
|
|
|
|
|
Closes #7743.
|
|
Preparatory work for removing unique vectors from the language, which is
itself preparatory work for dynamically sized types.
|
|
Currently, the format_args! macro and its downstream macros in turn
expand to series of let statements, one for each of its arguments, and
then the invocation of the macro function. If one or more of the
arguments are RefCell's, the enclosing statement for the temporary of
the let is the let itself, which leads to scope problem. This patch
changes let's to a match expression.
Closes #12239.
|
|
Currently, the format_args! macro and its downstream macros in turn
expand to series of let statements, one for each of its arguments, and
then the invocation of the macro function. If one or more of the
arguments are RefCell's, the enclosing statement for the temporary of
the let is the let itself, which leads to scope problem. This patch
changes let's to a match expression.
Closes #12239.
|
|
Closes #11692. Instead of returning the original expression, a dummy expression
(with identical span) is returned. This prevents infinite loops of failed
expansions as well as odd double error messages in certain situations.
|
|
|
|
|
|
Now that fold_item can return multiple items, this is pretty trivial. It
also recursively expands generated items so ItemDecorators can generate
items that are tagged with ItemDecorators!
Closes #4913
|
|
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
@huonw
|
|
|
|
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
|
|
The first setp for #9880 is to add a new `crate` keyword. This PR does exactly that. I took a chance to refactor `parse_item_foreign_mod` and I broke it down into 2 separate methods to isolate each feature.
The next step will be to push a new stage0 snapshot and then get rid of all `extern mod` around the code.
|
