| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:
* Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to
BasicMacroExpander, etc. I think "procedural macro" is the right
term for these now, right? The other option would be SynExtExpander
or something like that.
* Stop passing the SyntaxContext to extensions. This was only ever used
by macro_rules, which doesn't even use it anymore. I can't think of
a context in which an external extension would need it, and removal
allows the API to be significantly simpler - no more
SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
|
|
The old method of serializing the AST gives totally bogus spans if the
expansion of an imported macro causes compilation errors. The best
solution seems to be to serialize the actual textual macro definition
and load it the same way the std-macros are. I'm not totally confident
that getting the source from the CodeMap will always do the right thing,
but it seems to work in simple cases.
|
|
Consensus leaned in favour of using rev instead of flip.
|
|
Renamed the invert() function in iter.rs to flip().
Also renamed the Invert<T> type to Flip<T>.
Some related code comments changed. Documentation that I could find has
been updated, and all the instances I could locate where the
function/type were called have been updated as well.
|
|
The old method of serializing the AST gives totally bogus spans if the
expansion of an imported macro causes compilation errors. The best
solution seems to be to serialize the actual textual macro definition
and load it the same way the std-macros are. I'm not totally confident
that getting the source from the CodeMap will always do the right thing,
but it seems to work in simple cases.
|
|
|
|
It was the only span_* missing.
|
|
It was the only span_* missing.
|
|
This means that compilation continues for longer, and so we can see more
errors per compile. This is mildly more user-friendly because it stops
users having to run rustc n times to see n macro errors: just run it
once to see all of them.
|
|
|
|
|
|
|
|
This is necessary for #11151 to make sure dtors run before the libraries
are unloaded.
|
|
|
|
I'd really like to be able to do something like
```rust
struct MapChain<'next, K, V> {
info: BlockInfo,
map: HashMap<K, V>,
next: Option<&'next mut MapChain<'next, K, V>
}
```
but I can't get the lifetimes to work out.
|
|
|
|
|
|
This removes trait `handler` and `span_handler`,
and renames `HandlerT` to `Handler`, `CodemapT` to `SpanHandler`.
|
|
I'd really like to be able to do something like
struct MapChain<'next, K, V> {
info: BlockInfo,
map: HashMap<K, V>,
next: Option<&'next mut MapChain<'next, K, V>
}
but I can't get the lifetimes to work out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
|
|
|
|
Closes #4375
|
|
This also moves `#[auto_{en,de}code]` checker from syntax to lint.
|
|
|
|
This extension can be used to concatenate string literals at compile time. C has
this useful ability when placing string literals lexically next to one another,
but this needs to be handled at the syntax extension level to recursively expand
macros.
The major use case for this is something like:
macro_rules! mylog( ($fmt:expr $($arg:tt)*) => {
error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*);
})
Where the mylog macro will automatically prepend the filename/line number to the
beginning of every log message.
|
|
Who doesn't like a massive renaming?
|
|
It lived a good life, but its time has come. The groundwork is set for the
official transition after the next snapshot (removal of XXX2 macros)
|
|
|
|
For the benefit of the pretty printer we want to keep track of how
string literals in the ast were originally represented in the source
code.
This commit changes parser functions so they don't extract strings from
the token stream without at least also returning what style of string
literal it was. This is stored in the resulting ast node for string
literals, obviously, for the package id in `extern mod = r"package id"`
view items, for the inline asm in `asm!()` invocations.
For `asm!()`'s other arguments or for `extern "Rust" fn()` items, I just
the style of string, because it seemed disproportionally cumbersome to
thread that information through the string processing that happens with
those string literals, given the limited advantage raw string literals
would provide in these positions.
The other syntax extensions don't seem to store passed string literals
in the ast, so they also discard the style of strings they parse.
|
|
Treat it as a synonym for LIT_STR for now.
|
|
|
|
We're not outright removing fmt! just yet, but this prevents it from leaking
into the compiler further (it's still turned on by default for all other code).
|
|
|
|
|
|
This renames the syntax-extension file to format from ifmt, and it also reduces
the amount of complexity inside by defining all other macros in terms of
format_args!
|
|
The purpose of this macro is to further reduce the number of allocations which
occur when dealing with formatting strings. This macro will perform all of the
static analysis necessary to validate that a format string is safe, and then it
will wrap up the "format string" into an opaque struct which can then be passed
around.
Two safe functions are added (write/format) which take this opaque argument
structure, unwrap it, and then call the unsafe version of write/format (in an
unsafe block). Other than these two functions, it is not intended for anyone to
ever look inside this opaque struct.
The macro looks a bit odd, but mostly because of rvalue lifetimes this is the
only way for it to be safe that I know of.
Example use-cases of this are:
* third-party libraries can use the default formatting syntax without any
forced allocations
* the fail!() macro can avoid allocating the format string
* the logging macros can avoid allocation any strings
|
|
has a unique id. Fixes numerous bugs in macro expansion and deriving. Add two
representative tests.
Fixes #7971
Fixes #6304
Fixes #8367
Fixes #8754
Fixes #8852
Fixes #2543
Fixes #7654
|
|
This is actually almost a problem, because those were my poster-child
macros for "here's how to implement a capturing macro." Following this
change, there will be no macros that use capturing; this will probably
make life unpleasant for the first person that wants to implement a
capturing macro. I should probably create a dummy_capturing macro,
just to show how it works.
|
