Commit Graph

287 Commits

Author SHA1 Message Date
Aaron Hill
f916b0474a
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2021-05-12 00:51:31 -04:00
Dylan DPC
37c603864e
Rollup merge of #85075 - ptrojahn:panic_warning, r=jackh726
Improve "panic message is not a string literal" warning

This warning always referenced panic! even in case of an
assert. Related to #84656
2021-05-10 16:15:01 +02:00
Paul Trojahn
8f14592aa2 Improve "panic message is not a string literal" warning
This warning always referenced panic! even in case of an
assert. Related to #84656
2021-05-09 17:56:50 +02:00
Cameron Steffen
2e2bba94be Fix duplicate unknown lint errors 2021-05-07 17:26:32 -05:00
bors
7a0f1781d0 Auto merge of #83213 - rylev:update-lints-to-errors, r=nikomatsakis
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021

This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.

r? `@estebank`
2021-05-04 08:09:23 +00:00
Brent Kerby
6679f5ceb1 Change 'NULL' to 'null' 2021-05-02 17:46:00 -06:00
bors
ca075d268d Auto merge of #83386 - mark-i-m:stabilize-pat2015, r=nikomatsakis
Stabilize `:pat_param` and remove `:pat2021`

Blocked on #83384

cc `@rust-lang/lang` #79278

If I understand `@nikomatsakis` in  https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed.

r? `@nikomatsakis`
2021-04-28 20:35:17 +00:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
bors
c4ba8e3e5f Auto merge of #83799 - crlf0710:stablize_non_ascii_idents, r=Manishearth
Stablize `non-ascii-idents`

This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).

r? `@Manishearth`
2021-04-18 23:28:43 +00:00
bors
dc99219d3a Auto merge of #84064 - hyd-dev:unknown-lints, r=petrochenkov
Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Fixes #83477.
2021-04-18 02:12:13 +00:00
hyd-dev
ac044e35aa
Do not ignore path segments in the middle in #[allow]/#[warn]/#[deny]/#[forbid] attributes 2021-04-17 18:11:07 +08:00
mark
0566ccc72f rename pat2015 to pat_param 2021-04-15 13:52:09 -05:00
Aaron Hill
19c9d93ab5
Run buffered lints attached to anon consts
Fixes #84195
2021-04-15 11:11:44 -04:00
bors
7537b20626 Auto merge of #83948 - ABouttefeux:lint-nullprt-deref, r=RalfJung
add lint deref_nullptr detecting when a null ptr is dereferenced

fixes #83856
changelog: add lint that detect code like
```rust
unsafe {
      &*core::ptr::null::<i32>()
 };
unsafe {
     addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
 --> src\main.rs:5:26
  |
5 |     let x: i32 = unsafe {*core::ptr::null()};
  |                          ^^^^^^^^^^^^^^^^^^
  |                          |
  |                          a null pointer is dereferenced
  |                          this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default
```

Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
2021-04-14 18:04:22 +00:00
Ryan Levick
aa4457fa5f Add compatibility info to lints 2021-04-13 16:55:54 +02:00
Manish Goregaokar
664c3e71b8 Turn old edition lints (anonymous-parameters, keyword-idents) into warn-by-default on 2015 2021-04-12 09:45:59 -07:00
Aliénore Bouttefeux
79666c8857 changes based on review 2021-04-09 16:13:04 +02:00
Dylan DPC
74b23f9d11
Rollup merge of #83980 - pierwill:fix-compiler-librustc-names, r=davidtwco
Fix outdated crate names in compiler docs

Changes `librustc_X` to `rustc_X`, only in documentation comments.
Plain code comments are left unchanged.
2021-04-08 20:29:58 +02:00
Dylan DPC
9aed9c1353
Rollup merge of #81764 - jyn514:lint-links, r=GuillaumeGomez
Stabilize `rustdoc::bare_urls` lint

Closes https://github.com/rust-lang/rust/issues/77501. Closes https://github.com/rust-lang/rust/issues/83598.
2021-04-08 20:29:56 +02:00
pierwill
0019ca9141 Fix outdated crate names in compiler docs
Changes `librustc_X` to `rustc_X`, only in documentation comments.
Plain code comments are left unchanged.

Also fix incorrect file paths.
2021-04-08 11:12:14 -05:00
Ryan Levick
d7b226398e Change how edition is determined 2021-04-08 15:36:29 +02:00
Ryan Levick
c2d0f1457a Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 2021-04-08 15:36:27 +02:00
Aliénore Bouttefeux
0531ed0b62 fix lint doc 2021-04-08 12:09:32 +02:00
Aliénore Bouttefeux
3d215bdf42 change documentation of lint 2021-04-07 21:54:29 +02:00
Charles Lew
e5f9271f36 Stablize non_ascii_idents feature. 2021-04-08 02:52:00 +08:00
Aliénore Bouttefeux
c7bc41f97a add test 2021-04-07 19:23:17 +02:00
Aliénore Bouttefeux
389100921a add lint deref_nullptr 2021-04-06 22:01:00 +02:00
Joshua Nelson
d19083d9da Fix bug where rustc_lint would not apply renamed tool lints 2021-04-05 04:13:36 -04:00
Yuki Okushi
81f00c98a6 Trigger unused_doc_comments on macros at once 2021-04-04 05:06:51 +09:00
hi-rustin
2c66e15468 add OR_PATTERNS_BACK_COMPAT lint
test: add more cases

test: add comments

refine msg
2021-04-01 23:14:14 +08:00
Jack Huey
62a49c3bb8 Add tcx lifetime to Binder 2021-03-31 10:13:57 -04:00
Camille GILLOT
9d8f833e05 Remove hir::CrateItem. 2021-03-30 20:31:06 +02:00
Joshua Nelson
441dc3640a Remove (lots of) dead code
Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.
2021-03-27 22:16:33 -04:00
Dylan DPC
b2e254318d
Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se
Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
2021-03-27 20:37:07 +01:00
Ralf Jung
fb4f48e032 make unaligned_refereces future-incompat lint warn-by-default, and remove the safe_packed_borrows lint that it replaces 2021-03-27 16:59:37 +01:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
Dylan DPC
bcb9226efb
Rollup merge of #83216 - jyn514:register-tool, r=petrochenkov
Allow registering tool lints with `register_tool`

Previously, there was no way to add a custom tool prefix, even if the tool
itself had registered a lint:

 ```rust
 #![feature(register_tool)]
 #![register_tool(xyz)]
 #![warn(xyz::my_lint)]
 ```

```
$ rustc unknown-lint.rs  --crate-type lib
error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint`
 --> unknown-lint.rs:3:9
  |
3 | #![warn(xyz::my_lint)]
  |         ^^^
```

This allows opting-in to lints from other tools using `register_tool`.

cc https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, ``@chorman0773``
r? ``@petrochenkov``
2021-03-18 00:28:14 +01:00
bors
b4adc21c4f Auto merge of #83188 - petrochenkov:field, r=lcnr
ast/hir: Rename field-related structures

I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.

- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")

Various visiting and other methods working with the fields are renamed correspondingly too.

The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
2021-03-17 16:49:46 +00:00
Joshua Nelson
e3031fe22a Allow registering tool lints with register_tool
Previously, there was no way to add a custom tool prefix, even if the tool
itself had registered a lint:

 ```
 #![feature(register_tool)]
 #![register_tool(xyz)]
 #![warn(xyz::my_lint)]
 ```

```
$ rustc unknown-lint.rs  --crate-type lib
error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint`
 --> unknown-lint.rs:3:9
  |
3 | #![warn(xyz::my_lint)]
  |         ^^^
```

This allows opting-in to lints from other tools using `register_tool`.
2021-03-16 17:33:03 -04:00
Joshua Nelson
c1b99f0b90 Don't warn about old rustdoc lint names (temporarily)
Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.

To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.

This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
2021-03-16 13:13:59 -04:00
Vadim Petrochenkov
b25d3ba781 ast/hir: Rename field-related structures
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.
2021-03-16 11:41:24 +03:00
Aaron Hill
f190bc4f47
Introduce proc_macro_back_compat lint, and emit for time-macros-impl
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.

This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.

I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.

When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
2021-03-14 21:31:46 -04:00
Yuki Okushi
33614023a1
Rollup merge of #82798 - jyn514:rustdoc-group, r=Manishearth,GuillaumeGomez
Rename `rustdoc` to `rustdoc::all`

When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like

```
warning: unknown lint: `rustdoc`
```

The lint group still worked when rustdoc ran, since rustdoc added the group itself.

This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.

Follow-up to #80527.
r? ``@Manishearth``
2021-03-14 13:07:32 +09:00
Camille GILLOT
27ef0eeaa4 Track HirId when visiting attributes. 2021-03-09 19:27:59 +01:00
Camille GILLOT
c701872a6c Remove hir::Item::attrs. 2021-03-09 19:27:50 +01:00
Camille GILLOT
a987bbb97c Remove hir::Crate::attrs. 2021-03-09 19:22:55 +01:00
Camille GILLOT
c05c90275c Remove hir::MacroDef::attrs. 2021-03-09 19:09:36 +01:00
Camille GILLOT
4bb07bedf5 Visit attributes in one go. 2021-03-09 19:09:34 +01:00
Camille GILLOT
8e816056a5 Do not store attrs in FnKind. 2021-03-09 19:09:33 +01:00