| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix derive(PartialOrd) and optimise final field operation
```rust
// Before (`lt` on 2-field struct)
self.f1 < other.f1 || (!(other.f1 < self.f1) &&
(self.f2 < other.f2 || (!(other.f2 < self.f2) &&
(false)
))
)
// After
self.f1 < other.f1 || (!(other.f1 < self.f1) &&
self.f2 < other.f2
)
// Before (`le` on 2-field struct)
self.f1 < other.f1 || (!(other.f1 < self.f1) &&
(self.f2 < other.f2 || (!(other.f2 < self.f2) &&
(true)
))
)
// After
self.f1 < other.f1 || (self.f1 == other.f1 &&
self.f2 <= other.f2
)
```
(The big diff is mainly because of a past faulty rustfmt application that I corrected 😒)
Fixes #49650 and fixes #49505.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Retains the `stmt_expr_attributes` feature requirement for attributes on expressions.
closes #41475
cc #38356
|
|
Implement some trivial size_hints for various iterators
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
I intend to do more, but I don't want to make the PR too large.
|
|
Fix implicit closure return type generation for libsyntax
The `lambda` function for constructing closures in libsyntax was explicitly setting the return type to `_`, which resulted in incorrect corresponding syntax (as `|| -> _ x` is not valid, without the enclosing brackets). This meant the generated code, when printed, was invalid.
I also took the opportunity to slightly improve the generated code for the `RustcEncodable::encode` method for unit structs.
Fixes #42213.
|
|
|
|
lambda-building
This prevents explicit `-> _` return type annotations for closures generated by `lambda`.
|
|
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
|
|
|
|
syntax: Make imports in AST closer to the source and cleanup their parsing
This is a continuation of https://github.com/rust-lang/rust/pull/45846 in some sense.
|
|
|
|
|
|
Make `assert` a built-in procedural macro
Makes `assert` macro a built-in one without touching its functionality. This is a prerequisite for RFC 2011 (#44838).
|
|
check stability of macro invocations
I haven't implemented tests yet but this should be a pretty solid prototype. I think as-implemented it will also stability-check macro invocations in the same crate, dunno if we want that or not.
I don't know if we want this to go through `rustc::middle::stability` or not, considering the information there wouldn't be available at the time of macro expansion (even for external crates, right?).
r? @nrc
closes #34079
cc @petrochenkov @durka @jseyfried #38356
|
|
Payload of `Literal` token must be escaped.
Also print printable non-ASCII characters.
|
|
Fix hygene issue when deriving Debug
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
I also checked the implementations of the other built-in derives to
ensure they didn't declare any variables.
|
|
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
|
|
|
|
|
|
|
|
|
|
Comprehensively support trailing commas in std/core macros
I carefully organized the changes into four commits:
* Test cases
* Fixes for `macro_rules!` macros
* Fixes for builtin macros
* Docs for builtins
**I can easily scale this back to just the first two commits for now if such is desired.**
### Breaking (?) changes
* This fixes #48042, which is a breaking change that I hope people can agree is just a bugfix for an extremely dark corner case.
* To fix five of the builtins, this changes `syntax::ext::base::get_single_str_from_tts` to accept a trailing comma, and revises the documentation so that this aspect is not surprising. **I made this change under the (hopefully correct) understanding that `libsyntax` is private rustc implementation detail.** After reviewing all call sites (which were, you guessed it, *precisely those five macros*), I believe the revised semantics are closer to the intended spirit of the function.
### Changes which may require concensus
Up until now, it could be argued that some or all the following macros did not conceptually take a comma-separated list, because they only took one argument:
* **`cfg(unix,)`** (most notable since cfg! is unique in taking a meta tag)
* **`include{,_bytes,_str}("file.rs",)`** (in item form this might be written as "`include!{"file.rs",}`" which is even slightly more odd)
* **`compile_error("message",);`**
* **`option_env!("PATH",)`**
* **`try!(Ok(()),)`**
So I think these particular changes may require some sort of consensus. **All of the fixes for builtins are included this list, so if we want to defer these decisions to later then I can scale this PR back to just the first two commits.**
### Other notes/general requests for comment
* Do we have a big checklist somewhere of "things to do when adding macros?" My hope is for `run-pass/macro-comma-support.rs` to remain comprehensive.
* Originally I wanted the tests to also comprehensively forbid double trailing commas. However, this didn't work out too well: [see this gist and the giant FIXME in it](https://gist.github.com/ExpHP/6fc40e82f3d73267c4e590a9a94966f1#file-compile-fail_macro-comma-support-rs-L33-L50)
* I did not touch `select!`. It appears to me to be a complete mess, and its trailing comma mishaps are only the tip of the iceberg.
* There are [some compile-fail test cases](https://github.com/ExpHP/rust/blob/5fa97c35da2f0ee/src/test/compile-fail/macro-comma-behavior.rs#L49-L52) that didn't seem to work (rustc emits errors, but compile-fail doesn't acknowledge them), so they are disabled. Any clues? (Possibly related: These happen to be precisely the set of errors which are tagged by rustc as "this error originates in a macro outside of the current crate".)
---
Fixes #48042
Closes #46241
|
|
|
|
|
|
Most notably this changes 'syntax::ext::base::get_single_str_from_tts'
to accept a trailing comma, and revises the documentation so that this
aspect is not surprising. I made this change under the understanding
that this crate is private rustc implementation detail (I hope this is
correct!). After reviewing all call sites, I believe the revised
semantics are closer to the intended spirit of the function.
|
|
Make inline assembly volatile if it has no outputs. Fixes #46026
|
|
|
|
Add approximate suggestions for rustfix
This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "non-machine applicable" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.
fixes #39254
|
|
field only exist in the json if the flag is passed
|
|
|
|
errors
|
|
etaoins:fix-spurious-warning-on-empty-proc-macro-crate, r=alexcrichton
Fix spurious warning on empty proc macro crates
While attempting to reproduce rust-lang/rust#47086 I noticed the following warning:
```shell
> rustc /dev/null --crate-type proc-macro
warning: unused variable: `registrar`
--> /dev/null:0:1
```
As there are no macros to register the automatically generated registrar function for the crate has no body. As a result its `registrar` argument is unused triggering the above warning.
The warning is confusing and not easily actionable by the developer. It could also be triggered legitimately by e.g. having all of the macros in a crate #[cfg]'ed out.
Fix by naming the generated argument `_registrar` inside `mk_registrar()`. This suppresses the unused variable warning.
|
|
While attempting to reproduce rust-lang/rust#47086 I noticed the
following warning:
```shell
> rustc /dev/null --crate-type proc-macro
warning: unused variable: `registrar`
--> /dev/null:0:1
```
As there are no macros to register the automatically generated registrar
function for the crate has no body. As a result its `registrar` argument
is unused triggering the above warning.
The warning is confusing and not easily actionable by the developer. It
could also be triggered legitimately by e.g. having all of the macros in
a crate #[cfg]'ed out.
Fix by naming the generated argument `_registrar` inside
`mk_registrar()`. This suppresses the unused variable warning.
|
