Add an option to the parser to avoid parsing out of line modules
This is useful if parsing from stdin or a String and don't want to try and read in a module from another file. Instead we just leave a stub in the AST.
Correct some stability versions
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
This is useful if parsing from stdin or a String and don't want to try and read in a module from another file. Instead we just leave a stub in the AST.
Fix#35829 (`quote!()` does not handle `br#"…"#`)
Fix issue #35829 (syntax extension's `quote_expr!()` does not handle `b"…"` and proc_macro's `quote!()` does not handle `r#"…"#`)
* Handles `b"…"`, `br#"…"#` and `...` for `quote_expr!()`.
* Refactored the match statement to allow it to complain loudly on any unhandled token.
* Similarly, proc_macro's `quote!()` did not handle `br#"…"#` or `r#"…"#`, so this PR fixes it too.
Add lint for unused macros
Addresses parts of #34938, to add a lint for unused macros.
We now output warnings by default when we encounter a macro that we didn't use for expansion.
Issues to be resolved before this PR is ready for merge:
- [x] fix the NodeId issue described above
- [x] remove all unused macros from rustc and the libraries or set `#[allow(unused_macros)]` next to them if they should be kept for some reason. This is needed for successful boostrap and bors to accept the PR. -> #41934
- [x] ~~implement the full extent of #34938, that means the macro match arm checking as well.~~ *let's not do this for now*
Disallow ._ in float literal.
This patch makes lexer stop parsing number literals before `._`, as well as before `.a`. Underscore itself is still allowed like in `4_000_000.000_000_`.
Fixes a half part of #41723. The other is `""_`.
This commit extends the current unused macro linter
to support directives like #[allow(unused_macros)]
or #[deny(unused_macros)] directly next to the macro
definition, or in one of the modules the macro is
inside. Before, we only supported such directives
at a per crate level, due to the crate's NodeId
being passed to session.add_lint.
We also had to implement handling of the macro's
NodeId in the lint visitor.
* Handles `b"…"`, `br#"…"#` and `...` for `quote_expr!()`.
* Refactored the match statement to allow it to complain loudly on any
unhandled token.
* Similarly, proc_macro's `quote!()` did not handle `br#"…"#` or `r#"…"#`,
so this commit fixes it too.
incr.comp.: Hash more pieces of crate metadata to detect changes there.
This PR adds incr. comp. hashes for non-`Entry` pieces of data in crate metadata.
The first part of it I like: `EntryBuilder` is refactored into the more generally applicable `IsolatedEncoder` which provides means of encoding something into metadata while also feeding the encoded data into an incr. comp. hash. We already did this for `Entry`, now we are doing it for various other pieces of data too, like the set of exported symbols and so on. The hashes generated there are persisted together with the per-`Entry` hashes and are also used for dep-graph dirtying the same way.
The second part of the PR I'm not entirely happy with: In order to make sure that we don't forget registering a read to the new `DepNodes` introduced here, I added the `Tracked<T>` struct. This struct wraps a value and requires a `DepNode` when accessing the wrapped value. This makes it harder to overlook adding read edges in the right places and works just fine.
However, crate metadata is already used in places where there is no `tcx` yet or even in places where no `cnum` has been assigned -- this makes it harder to apply this feature consistently or implement it ergonomically. The result is not too bad but there's a bit more code churn and a bit more opportunity to get something wrong than I would have liked. On the other hand, wrapping things in `Tracked<T>` already has revealed some bugs, so there's definitely some value in it.
This is still a work in progress:
- [x] I need to write some test cases.
- [x] Accessing the CodeMap should really be dependency tracked too, especially with the new path-remapping feature.
cc @nikomatsakis
Suggest `!` for bitwise negation when encountering a `~`
Fix#41679
Here is a program
```rust
fn main() {
let x = ~1;
}
```
It's output:
```
error: `~` can not be used as an unary operator
--> /home/fcc/temp/test.rs:4:13
|
4 | let x = ~1;
| ^^
|
= help: use `!` instead of `~` if you meant to bitwise negation
```
cc @bstrie
