| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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.
|
|
Implement repr(transparent)
r? @eddyb for the functional changes. The bulk of the PR is error messages and docs, might be good to have a doc person look over those.
cc #43036
cc @nox
|
|
|
|
|
|
Avoid overlapping spans by only pointing at the arguments that are not
being used in the argument string. Enable libsyntax to have diagnostics
with multiple primary spans by accepting `Into<MultiSpan>` instead of
`Span`.
|
|
locals that mentioned "extern repr"
|
|
|
|
|
|
Do not emit type errors on recovered blocks
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
Fix #44579.
|
|
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
|
|
The Generics now contain one Vec of an enum for the generic parameters,
rather than two separate Vec's for lifetime and type parameters.
Additionally, places that previously used Vec<LifetimeDef> now use
Vec<GenericParam> instead.
|
|
macros: hygienize use of `core`/`std` in builtin macros
Today, if a builtin macro wants to access an item from `core` or `std` (depending `#![no_std]`), it generates `::core::path::to::item` or `::std::path::to::item` respectively (c.f. `fn std_path()` in `libsyntax/ext/base.rs`).
This PR refactors the builtin macros to instead always emit `$crate::path::to::item` here. That is, the def site of builtin macros is taken to be in `extern crate core;` or `extern crate std;`. Since builtin macros are macros 1.0 (i.e. mostly unhygienic), changing the def site can only effect the resolution of `$crate`.
r? @nrc
|
|
|
|
|
|
Account for missing keyword in fn/struct definition
Fix #38911.
|
|
|
|
Fix the derive implementation for repr(packed) structs to move the
fields out instead of calling functions on references to each subfield.
That's it, `#[derive(PartialEq)]` on a packed struct now does:
```Rust
fn eq(&self, other: &Self) {
let field_0 = self.0;
let other_field_0 = other.0;
&field_0 == &other_field_0
}
```
Instead of
```Rust
fn eq(&self, other: &Self) {
let ref field_0 = self.0;
let ref other_field_0 = other.0;
&*field_0 == &*other_field_0
}
```
Taking (unaligned) references to each subfield is undefined, unsound and
is an error with MIR effectck, so it had to be prevented. This causes
a borrowck error when a `repr(packed)` struct has a non-Copy field (and
therefore is a [breaking-change]), but I don't see a sound way to avoid
that error.
|
|
|
|
|
|
|
|
support generics in each variant of TraitItem and ImplItem
|
|
A slight eccentricity of this change is that now non-ADT-derive errors prevent
derive-macro-not-found errors from surfacing (see changes to the
gating-of-derive compile-fail tests).
Resolves #43927.
|
|
|
|
|
|
|
|
|
|
Fixes #41701.
|
|
Fix typos & us spellings
Fixing some typos and non en-US spellings.
(Update of PR https://github.com/rust-lang/rust/pull/42812 )
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Fixed mutable vars being marked used when they weren't
#### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue.
Fixes #43526, Fixes #30280, Fixes #25049
### Issue
Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings
```
fn do_thing<T>(mut arg : &mut T) {
... // don't touch arg - just deref it to access the T
}
```
### Fix
Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables.
#### Why not on things other than local variables?
* Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted.
* If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
|
|
@alexcrichton figured out a way how to do it :)
|
|
|
|
|
|
Three small fixes for save-analysis
First commit does some naive deduplication of macro uses. We end up with lots of duplication here because of the weird way we get this data (we extract a use for every span generated by a macro use).
Second commit is basically a typo fix.
Third commit is a bit interesting, it partially reverts a change from #40939 where temporary variables in format! (and thus println!) got a span with the primary pointing at the value stored into the temporary (e.g., `x` in `println!("...", x)`). If `format!` had a definition it should point at the temporary in the macro def, but since it is built-in, that is not possible (for now), so `DUMMY_SP` is the best we can do (using the span in the callee really breaks save-analysis because it thinks `x` is a definition as well as a reference).
There aren't a test for this stuff because: the deduplication is filtered by any of the users of save-analysis, so it is purely an efficiency change. I couldn't actually find an example for the second commit that we have any machinery to test, and the third commit is tested by the RLS, so there will be a test once I update the RLS version and and uncomment the previously failing tests).
r? @jseyfried
|
|
Add Span to ast::WhereClause
This PR adds `Span` field to `ast::WhereClause`. The motivation here is to make rustfmt's life easier when recovering comments before and after where clause.
r? @nrc
|
