Commit Graph

433 Commits

Author SHA1 Message Date
Yuki Okushi
4f8e0ebcc5
Use AttrVec for Arm, FieldDef, and Variant 2021-06-17 08:04:54 +09:00
Ryan Levick
6936349233 Add support for using qualified paths with structs in expression and pattern
position.
2021-06-10 13:18:41 +02:00
asquared31415
9b2ba6d1a1 Fix ICE when main is declared in an extern block 2021-06-09 23:14:02 -04:00
bors
86b0bafbf1 Auto merge of #84995 - petrochenkov:tcollect, r=Aaron1011
parser: Ensure that all nonterminals have tokens after parsing

`parse_nonterminal` should always result in something with tokens.

This requirement wasn't satisfied in two cases:
- `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases.
- `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert.

(Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.)

r? `@Aaron1011`
2021-06-06 14:00:43 +00:00
Vadim Petrochenkov
cbdfa1edca parser: Ensure that all nonterminals have tokens after parsing 2021-06-06 14:21:12 +03:00
Yuki Okushi
2f0a8556a9
Rollup merge of #86043 - klensy:attr-clone, r=jyn514
don't clone attrs
2021-06-06 19:11:23 +09:00
Camille Gillot
0f0f3138cb
Revert "Reduce the amount of untracked state in TyCtxt" 2021-06-01 09:05:22 +02:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
klensy
56a2a2ae1f don't clone attrs 2021-05-30 22:44:40 +03:00
Camille GILLOT
ee94fbb607 Make allocator_kind a query. 2021-05-30 19:58:01 +02:00
Jacob Pratt
bc2f0fb5a9
Specialize implementations
Implementations in stdlib are now optimized as they were before.
2021-05-26 18:07:09 -04:00
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
Ralf Jung
65cd051b4a stabilize const_fn_unsize 2021-05-22 10:35:49 +02:00
jedel1043
059b68dd67 Implement Anonymous{Struct, Union} in the AST
Add unnamed_fields feature gate and gate unnamed fields on parsing
2021-05-16 09:49:16 -05:00
Amanieu d'Antras
5918ee4317 Add support for const operands and options to global_asm!
On x86, the default syntax is also switched to Intel to match asm!
2021-05-13 22:31:57 +01:00
Giacomo Stevanato
b1c8835a0f Add more precise span informations to generic types 2021-05-12 11:36:07 +02: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
mark
2a9db919ff remove pat2021 2021-04-27 21:15:59 -05:00
bors
b56b175c6c Auto merge of #84310 - RalfJung:const-fn-feature-flags, r=oli-obk
further split up const_fn feature flag

This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)

I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.

`@oli-obk` are you currently able to do reviews?
2021-04-24 23:16:03 +00:00
bors
e888a57da8 Auto merge of #84334 - klensy:typo-compiler, r=jyn514
fix few typos in comments
2021-04-20 00:16:45 +00:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
Ralf Jung
bd9556956a fix feature use in rustc libs 2021-04-18 22:05:45 +02:00
mark
0566ccc72f rename pat2015 to pat_param 2021-04-15 13:52:09 -05:00
Aaron Hill
a93c4f05de
Implement token-based handling of attributes during expansion
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:

* Derives macros no longer lose spans when their input is modified
  by eager cfg-expansion. This is accomplished by performing eager
  cfg-expansion on the token stream that we pass to the derive
  proc-macro
* Inner attributes now preserve spans in all cases, including when we
  have multiple inner attributes in a row.

This is accomplished through the following changes:

* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
  These are very similar to a normal `TokenTree`, but they also track
  the position of attributes and attribute targets within the stream.
  They are built when we collect tokens during parsing.
  An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
  we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
  `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
  is created during the parsing of a nested AST node to make the 'outer'
  AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`),
we tokenize and reparse our target, capturing additional information about the locations of
`#[cfg]` and `#[cfg_attr]` attributes at any depth within the target.
This is a performance optimization, allowing us to perform less work
in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-11 01:31:36 -04:00
Tomasz Miąsko
985ae0b55b Match against attribute name when validating attributes
Extract attribute name once and match it against symbols that are being
validated, instead of using `Session::check_name` for each symbol
individually.

Assume that all validated attributes are used, instead of marking them
as such, since the attribute check should be exhaustive.
2021-04-11 00:00:00 +00: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
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
Dylan DPC
b81c6cdb57
Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkov
Use AnonConst for asm! constants

This replaces the old system which used explicit promotion. See #83169 for more background.

The syntax for `const` operands is still the same as before: `const <expr>`.

Fixes #83169

Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
2021-04-07 13:07:14 +02:00
Amanieu d'Antras
32be124e30 Use AnonConst for asm! constants 2021-04-06 12:35:41 +01:00
Guillaume Gomez
f4a19ca851
Fix typo in TokenStream documentation 2021-04-05 22:58:07 +02:00
Jubilee Young
a7e808ed25 Add notes 2021-04-04 20:12:26 -07: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
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
Yuki Okushi
50d048f142
Rollup merge of #83384 - mark-i-m:rename-pat2018, r=joshtriplett
rename :pat2018 -> :pat2015

as requested by T-lang on zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873

No functional changes here... just renaming.

r? `@nikomatsakis`
2021-03-23 10:15:43 +09:00
mark
8c4b3dbb50 rename :pat2018 -> :pat215 2021-03-22 12:40:23 -05:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
bors
2aafe452b8 Auto merge of #82868 - petrochenkov:bto, r=estebank
Report missing cases of `bare_trait_objects`

Fixes https://github.com/rust-lang/rust/issues/65371
2021-03-18 05:27:26 +00:00
Vadim Petrochenkov
38ed36bba4 hir: Preserve used syntax in TyKind::TraitObject 2021-03-18 03:02:32 +03: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
Dylan DPC
7cd7dee315
Rollup merge of #83168 - Aaron1011:lint-procedural-masquerade, r=petrochenkov
Extend `proc_macro_back_compat` lint to `procedural-masquerade`

We now lint on *any* use of `procedural-masquerade` crate. While this
crate still exists, its main reverse dependency (`cssparser`) no longer
depends on it. Any crates still depending off should stop doing so, as
it only exists to support very old Rust versions.

If a crate actually needs to support old versions of rustc via
`procedural-masquerade`, then they'll just need to accept the warning
until we remove it entirely (at the same time as the back-compat hack).
The latest version of `procedural-masquerade` does work with the
latest rustc, but trying to check for the version seems like more
trouble than it's worth.

While working on this, I realized that the `proc-macro-hack` check was
never actually doing anything. The corresponding enum variant in
`proc-macro-hack` is named `Value` or `Nested` - it has never been
called `Input`. Due to a strange Crater issue, the Crater run that
tested adding this did *not* end up testing it - some of the crates that
would have failed did not actually have their tests checked, making it
seem as though the `proc-macro-hack` check was working.

The Crater issue is being discussed at
https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661

Despite the `proc-macro-hack` check not actually doing anything, we
haven't gotten any reports from users about their build being broken.
I went ahead and removed it entirely, since it's clear that no one is
being affected by the `proc-macro-hack` regression in practice.
2021-03-18 00:28:10 +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
Vadim Petrochenkov
d1522b39dd ast: Reduce size of ExprKind by boxing fields of ExprKind::Struct 2021-03-16 11:41:24 +03: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
d6a7c1d47f
Extend proc_macro_back_compat lint to procedural-masquerade
We now lint on *any* use of `procedural-masquerade` crate. While this
crate still exists, its main reverse dependency (`cssparser`) no longer
depends on it. Any crates still depending off should stop doing so, as
it only exists to support very old Rust versions.

If a crate actually needs to support old versions of rustc via
`procedural-masquerade`, then they'll just need to accept the warning
until we remove it entirely (at the same time as the back-compat hack).
The latest version of `procedural-masquerade` does not work with the
latest rustc, but trying to check for the version seems like more
trouble than it's worth.

While working on this, I realized that the `proc-macro-hack` check was
never actually doing anything. The corresponding enum variant in
`proc-macro-hack` is named `Value` or `Nested` - it has never been
called `Input`. Due to a strange Crater issue, the Crater run that
tested adding this did *not* end up testing it - some of the crates that
would have failed did not actually have their tests checked, making it
seem as though the `proc-macro-hack` check was working.

The Crater issue is being discussed at
https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661

Despite the `proc-macro-hack` check not actually doing anything, we
haven't gotten any reports from users about their build being broken.
I went ahead and removed it entirely, since it's clear that no one is
being affected by the `proc-macro-hack` regression in practice.
2021-03-15 16:00:49 -04:00
Vadim Petrochenkov
7e66e9d6b0 More precise spans for HIR paths 2021-03-15 22:13:45 +03:00
Dylan DPC
d1f5f1d156
Rollup merge of #83127 - Aaron1011:time-macros-impl-warn, r=petrochenkov
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-15 16:22:57 +01:00
Dylan DPC
b8622f2b3b
Rollup merge of #83054 - tmiasko:rustc_layout_scalar_valid_range, r=davidtwco
Validate rustc_layout_scalar_valid_range_{start,end} attributes

Fixes #82251, fixes #82981.
2021-03-15 16:22:51 +01: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
Vadim Petrochenkov
a4cc3cae04 expand: Resolve and expand inner attributes on out-of-line modules 2021-03-14 18:10:29 +03:00
Tomasz Miąsko
1ba71abddd Inline Attribute::has_name 2021-03-11 16:04:14 +01:00
Mara Bos
bb9542b016
Rollup merge of #82841 - hvdijk:x32, r=joshtriplett
Change x64 size checks to not apply to x32.

Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.
2021-03-09 09:05:24 +00:00
Mara Bos
6a55aa1246
Rollup merge of #82854 - estebank:issue-82827, r=oli-obk
Account for `if (let pat = expr) {}`

Fix #82827.
2021-03-08 20:09:02 +01:00
Dylan DPC
9c310571a8
Rollup merge of #82682 - petrochenkov:cfgeval, r=Aaron1011
Implement built-in attribute macro `#[cfg_eval]` + some refactoring

This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes.

The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input).
The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items.

`cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`.

```rust
#[cfg_eval]
#[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]`
struct S {
    #[cfg(FALSE)]
    field: u8,
}
```

Tracking issue: https://github.com/rust-lang/rust/issues/82679
2021-03-08 13:13:23 +01:00
bors
76c500ec6c Auto merge of #81635 - michaelwoerister:structured_def_path_hash, r=pnkfelix
Let a portion of DefPathHash uniquely identify the DefPath's crate.

This allows to directly map from a `DefPathHash` to the crate it originates from, without constructing side tables to do that mapping -- something that is useful for incremental compilation where we deal with `DefPathHash` instead of `DefId` a lot.

It also allows to reliably and cheaply check for `DefPathHash` collisions which allows the compiler to gracefully abort compilation instead of running into a subsequent ICE at some random place in the code.

The following new piece of documentation describes the most interesting aspects of the changes:

```rust
/// A `DefPathHash` is a fixed-size representation of a `DefPath` that is
/// stable across crate and compilation session boundaries. It consists of two
/// separate 64-bit hashes. The first uniquely identifies the crate this
/// `DefPathHash` originates from (see [StableCrateId]), and the second
/// uniquely identifies the corresponding `DefPath` within that crate. Together
/// they form a unique identifier within an entire crate graph.
///
/// There is a very small chance of hash collisions, which would mean that two
/// different `DefPath`s map to the same `DefPathHash`. Proceeding compilation
/// with such a hash collision would very probably lead to an ICE and, in the
/// worst case, to a silent mis-compilation. The compiler therefore actively
/// and exhaustively checks for such hash collisions and aborts compilation if
/// it finds one.
///
/// `DefPathHash` uses 64-bit hashes for both the crate-id part and the
/// crate-internal part, even though it is likely that there are many more
/// `LocalDefId`s in a single crate than there are individual crates in a crate
/// graph. Since we use the same number of bits in both cases, the collision
/// probability for the crate-local part will be quite a bit higher (though
/// still very small).
///
/// This imbalance is not by accident: A hash collision in the
/// crate-local part of a `DefPathHash` will be detected and reported while
/// compiling the crate in question. Such a collision does not depend on
/// outside factors and can be easily fixed by the crate maintainer (e.g. by
/// renaming the item in question or by bumping the crate version in a harmless
/// way).
///
/// A collision between crate-id hashes on the other hand is harder to fix
/// because it depends on the set of crates in the entire crate graph of a
/// compilation session. Again, using the same crate with a different version
/// number would fix the issue with a high probability -- but that might be
/// easier said then done if the crates in questions are dependencies of
/// third-party crates.
///
/// That being said, given a high quality hash function, the collision
/// probabilities in question are very small. For example, for a big crate like
/// `rustc_middle` (with ~50000 `LocalDefId`s as of the time of writing) there
/// is a probability of roughly 1 in 14,750,000,000 of a crate-internal
/// collision occurring. For a big crate graph with 1000 crates in it, there is
/// a probability of 1 in 36,890,000,000,000 of a `StableCrateId` collision.
```

Given the probabilities involved I hope that no one will ever actually see the error messages. Nonetheless, I'd be glad about some feedback on how to improve them. Should we create a GH issue describing the problem and possible solutions to point to? Or a page in the rustc book?

r? `@pnkfelix` (feel free to re-assign)
2021-03-07 23:45:57 +00:00
Esteban Küber
e62a543344 Account for if (let pat = expr) {}
Partially address #82827.
2021-03-07 13:49:36 -08:00
Vadim Petrochenkov
069e612e73 rustc_ast: Replace AstLike::finalize_tokens with a getter tokens_mut 2021-03-06 21:19:31 +03:00
Harald van Dijk
95e096d623
Change x64 size checks to not apply to x32.
Rust contains various size checks conditional on target_arch = "x86_64",
but these checks were never intended to apply to
x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the
conditions.
2021-03-06 16:02:48 +00:00
Joshua Nelson
cc62018e61 Rename rustdoc lints to be a tool lint instead of built-in.
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links`
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests

  Otherwise, all `rustdoc::` lints would be ignored.

- Register all existing lints as removed

  This unfortunately doesn't work with `register_renamed` because tool
  lints have not yet been registered when rustc is running. For similar
  reasons, `check_backwards_compat` doesn't work either. Call
  `register_removed` directly instead.

- Fix fallout

  + Rustdoc lints for compiler/
  + Rustdoc lints for library/

Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for
`rustdoc::intra_doc_link_resolution_failure`, since there was no time
when the latter was valid.
2021-03-01 19:29:15 -05:00
Aaron Hill
fb5fec017b
Combine HasAttrs and HasTokens into AstLike
When token-based attribute handling is implemeneted in #80689,
we will need to access tokens from `HasAttrs` (to perform
cfg-stripping), and we will to access attributes from `HasTokens` (to
construct a `PreexpTokenStream`).

This PR merges the `HasAttrs` and `HasTokens` traits into a new
`AstLike` trait. The previous `HasAttrs` impls from `Vec<Attribute>` and `AttrVec`
are removed - they aren't attribute targets, so the impls never really
made sense.
2021-02-27 00:14:13 -05:00
Dylan DPC
20928e0cbf
Rollup merge of #82321 - bugadani:ast3, r=varkor
AST: Remove some unnecessary boxes
2021-02-25 14:34:03 +01:00
Simon Vandel Sillesen
2d1e0adfe9 New pass to deduplicate blocks 2021-02-21 21:51:54 +01:00
Dániel Buga
10f234240d Remove some P-s 2021-02-20 10:51:26 +01:00
Vadim Petrochenkov
4a88165124 ast: Keep expansion status for out-of-line module items
Also remove `ast::Mod` which is mostly redundant now
2021-02-18 13:07:49 +03:00
Vadim Petrochenkov
eb65f15c78 ast: Stop using Mod in Crate
Crate root is sufficiently different from `mod` items, at least at syntactic level.

Also remove customization point for "`mod` item or crate root" from AST visitors.
2021-02-18 13:07:49 +03:00
bors
9503ea19ed Auto merge of #82103 - Dylan-DPC:rollup-5wv8rid, r=Dylan-DPC
Rollup of 11 pull requests

Successful merges:

 - #80523 (#[doc(inline)] sym_generated)
 - #80920 (Visit more targets when validating attributes)
 - #81720 (Updated smallvec version due to RUSTSEC-2021-0003)
 - #81891 ([rustdoc-json] Make `header` a vec of modifiers, and FunctionPointer consistent)
 - #81912 (Implement the precise analysis pass for lint `disjoint_capture_drop_reorder`)
 - #81914 (Fixing bad suggestion for `_` in `const` type when a function #81885)
 - #81919 (BTreeMap: fix internal comments)
 - #81927 (Add a regression test for #32498)
 - #81965 (Fix MIR pretty printer for non-local DefIds)
 - #82029 (Use debug log level for developer oriented logs)
 - #82056 (fix ice (#82032))

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-02-14 22:26:21 +00:00
klensy
93c8ebe022 bumped smallvec deps 2021-02-14 18:03:11 +03:00
Aaron Hill
0b411f56e1
Require passing an AttrWrapper to collect_tokens_trailing_token
This is a pure refactoring split out from #80689.
It represents the most invasive part of that PR, requiring changes in
every caller of `parse_outer_attributes`

In order to eagerly expand `#[cfg]` attributes while preserving the
original `TokenStream`, we need to know the range of tokens that
corresponds to every attribute target. This is accomplished by making
`parse_outer_attributes` return an opaque `AttrWrapper` struct. An
`AttrWrapper` must be converted to a plain `AttrVec` by passing it to
`collect_tokens_trailing_token`. This makes it difficult to accidentally
construct an AST node with attributes without calling `collect_tokens_trailing_token`,
since AST nodes store an `AttrVec`, not an `AttrWrapper`.

As a result, we now call `collect_tokens_trailing_token` for attribute
targets which only support inert attributes, such as generic arguments
and struct fields. Currently, the constructed `LazyTokenStream` is
simply discarded. Future PRs will record the token range corresponding
to the attribute target, allowing those tokens to be removed from an
enclosing `collect_tokens_trailing_token` call if necessary.
2021-02-13 12:07:15 -05:00
bors
9ce7268bcf Auto merge of #80860 - camelid:nodeid-docs, r=sanxiyn
Document `NodeId`
2021-02-11 00:51:45 +00:00
Camelid
0f3e2f68d3 Clarify docs for DUMMY_NODE_ID 2021-02-07 19:42:12 -08:00
Mara Bos
87b269ab66
Rollup merge of #81645 - m-ou-se:panic-lint, r=estebank,flip1995
Add lint for `panic!(123)` which is not accepted in Rust 2021.

This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021.

It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.

It renames the lint to `non_fmt_panic` to match the lint naming guidelines.

![image](https://user-images.githubusercontent.com/783247/106520928-675ea680-64d5-11eb-81f7-d8fa48b93a0b.png)

This is part of #80162.

r? ```@estebank```
2021-02-04 21:10:36 +01:00
Mara Bos
24e0940169 Stabilize feature(iterator_fold_self): Iterator::reduce 2021-02-04 11:31:11 +01:00
Mara Bos
34d5ac25c5 Make panic/assert calls in rustc compatible with Rust 2021. 2021-02-03 22:42:53 +01:00
Michael Woerister
22d489be76 Let a portion of DefPathHash uniquely identify the DefPath's crate.
This allows to directly map from a DefPathHash to the crate it
originates from, without constructing side tables to do that mapping.

It also allows to reliably and cheaply check for DefPathHash collisions.
2021-02-02 17:40:29 +01:00
Dániel Buga
003fba3fda Assert the size of the refactored enums 2021-02-01 09:23:40 +01:00
Dániel Buga
b87e1ecdf0 Box the biggest ast::ItemKind variants 2021-02-01 09:23:39 +01:00
Aaron Hill
ccfc292999
Refactor token collection to capture trailing token immediately 2021-01-22 00:33:03 -05:00
wcampbell
e23acc341c
Replace let Some(..) = with .is_some()
Signed-off-by: wcampbell <wcampbell1995@gmail.com>
2021-01-17 19:06:12 -05:00
Dániel Buga
dc932cdf88 Remove unnecessary manual shrink_to_fit calls 2021-01-16 14:02:36 +01:00
bors
dcf622eb70 Auto merge of #80993 - Aaron1011:collect-set-tokens, r=petrochenkov
Set tokens on AST node in `collect_tokens`

A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.

In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
2021-01-15 05:36:48 +00:00
Aaron Hill
a961e6785c
Set tokens on AST node in collect_tokens
A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.

In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
2021-01-13 22:10:36 -05:00
Camelid
2af4a01450 Document NodeId 2021-01-11 18:12:15 -08:00
Patryk Wychowaniec
d2f8e398f1
Rework diagnostics for wrong number of generic args 2021-01-10 13:07:40 +01:00
Vadim Petrochenkov
71cd6f42a6 ast: Remove some indirection layers from values in key-value attributes 2021-01-09 21:50:39 +03:00
Yuki Okushi
695f878332
Rollup merge of #80784 - petrochenkov:nontspan, r=Aaron1011
rustc_parse: Better spans for synthesized token streams

I think using the nonterminal span for synthesizing its tokens is a better approximation than using `DUMMY_SP` or the attribute span like #79472 did in `expand.rs`.

r? `@Aaron1011`
2021-01-08 02:06:20 +09:00
Yuki Okushi
d02b31ca3c
Rollup merge of #80659 - pierwill:edit-tokenstream, r=davidtwco
Edit rustc_ast::tokenstream docs

Fix some punctuation and wording, and add intra-documentation links.
2021-01-08 02:06:07 +09:00
Vadim Petrochenkov
0dab076358 rustc_parse: Better spans for synthesized token streams 2021-01-07 17:48:13 +03:00
pierwill
9a240e4857 Edit rustc_ast::tokenstream docs
Fix some punctuation and wording, and add intra-documentation links.
2021-01-03 11:54:56 -08:00
Matthias Krüger
8a90626a46 reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats) 2021-01-02 20:09:17 +01:00
Julian Knodt
61f33bfd29 first pass at default values for const generics
- Adds optional default values to const generic parameters in the AST
  and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate
2021-01-01 10:55:10 +01:00
Mara Bos
3cbdbe8dcd Enable Pat2021 in edition 2021. 2020-12-31 19:39:44 +01:00
bors
44e3daf5ee Auto merge of #80459 - mark-i-m:or-pat-reg, r=petrochenkov
Implement edition-based macro :pat feature

This PR does two things:
1. Fixes the perf regression from https://github.com/rust-lang/rust/pull/80100#issuecomment-750893149
2. Implements `:pat2018` and `:pat2021` matchers, as described by `@joshtriplett`  in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090 behind the feature gate `edition_macro_pat`.

r? `@petrochenkov`

cc `@Mark-Simulacrum`
2020-12-31 14:52:26 +00:00
Mara Bos
3d7cdf667e
Rollup merge of #80128 - pierwill:pierwill-docs-fieldpat, r=jyn514
Edit rustc_ast::ast::FieldPat docs

Punctuation fixes.
2020-12-30 20:56:49 +00:00
mark
40bf3c0f09 Implement edition-based macro pat feature 2020-12-30 09:57:49 -06:00
bors
d107a87d34 Auto merge of #80503 - JohnTitor:rollup-b26vglu, r=JohnTitor
Rollup of 13 pull requests

Successful merges:

 - #79812 (Lint on redundant trailing semicolon after item)
 - #80348 (remove redundant clones (clippy::redundant_clone))
 - #80358 (Edit rustc_span documentation)
 - #80457 (Add missing commas to `rustc_ast_pretty::pp` docs)
 - #80461 (Add llvm-libunwind change to bootstrap CHANGELOG)
 - #80464 (Use Option::map_or instead of open coding it)
 - #80465 (Fix typo in ffi-pure.md)
 - #80467 (More uses of the matches! macro)
 - #80469 (Fix small typo in time comment)
 - #80472 (Use sans-serif font for the "all items" page links)
 - #80477 (Make forget intrinsic safe)
 - #80482 (don't clone copy types)
 - #80487 (don't redundantly repeat field names)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2020-12-30 09:51:42 +00:00
LingMan
7a41532ef9 More uses of the matches! macro 2020-12-29 17:18:52 +01:00
Aaron Hill
530a629635
Remove pretty-print/reparse hack, and add derive-specific hack 2020-12-29 09:36:42 -05:00
Dylan DPC
c51172f38a
Rollup merge of #80344 - matthiaskrgr:matches, r=Dylan-DPC
use matches!() macro in more places
2020-12-28 14:13:12 +01:00
Bastian Kauschke
06cc9c26da stabilize min_const_generics 2020-12-26 18:24:10 +01:00
Matthias Krüger
d12a358673 use matches!() macro in more places 2020-12-24 13:35:12 +01:00
Guillaume Gomez
64afdedfb8 Rework beautify_doc_string so that it returns a Symbol instead of a String 2020-12-22 16:05:38 +01:00
pierwill
30c9307bfc
docs: Edit rustc_ast::token::Token
Add missing punctuation.
2020-12-17 11:55:49 -08:00
pierwill
613cc9bb45 Edit rustc_ast::ast::FieldPat docs
Punctuation fixes.
2020-12-17 11:39:39 -08:00
Vadim Petrochenkov
31d72c2658 Accept arbitrary expressions in key-value attributes at parse time 2020-12-09 21:37:32 +03:00
Guillaume Gomez
a2d1254e22 Add documentation for name_value_literal_span methods 2020-12-01 17:32:14 +01:00
Guillaume Gomez
63816da5ed Improve some attributes error spans 2020-12-01 16:26:51 +01:00
Guillaume Gomez
7df0052df8 Created NestedMetaItem::name_value_literal_span method 2020-12-01 16:26:51 +01:00
bors
4ae328bef4 Auto merge of #78296 - Aaron1011:fix/stmt-tokens, r=petrochenkov
Properly handle attributes on statements

We now collect tokens for the underlying node wrapped by `StmtKind`
nstead of storing tokens directly in `Stmt`.

`LazyTokenStream` now supports capturing a trailing semicolon after it
is initially constructed. This allows us to avoid refactoring statement
parsing to wrap the parsing of the semicolon in `parse_tokens`.

Attributes on item statements
(e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as
item attributes, not statement attributes, which is consistent with how
we handle attributes on other kinds of statements. The feature-gating
code is adjusted so that proc-macro attributes are still allowed on item
statements on stable.

Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be
adjusted to support being passed `Annotatable::Stmt`.
2020-11-28 07:48:56 +00:00
bors
cfed9184f4 Auto merge of #79266 - b-naber:gat_trait_path_parser, r=petrochenkov
Generic Associated Types in Trait Paths - Ast part

The Ast part of https://github.com/rust-lang/rust/pull/78978

r? `@petrochenkov`
2020-11-27 00:18:24 +00:00
Aaron Hill
de88bf148b
Properly handle attributes on statements
We now collect tokens for the underlying node wrapped by `StmtKind`
instead of storing tokens directly in `Stmt`.

`LazyTokenStream` now supports capturing a trailing semicolon after it
is initially constructed. This allows us to avoid refactoring statement
parsing to wrap the parsing of the semicolon in `parse_tokens`.

Attributes on item statements
(e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as
item attributes, not statement attributes, which is consistent with how
we handle attributes on other kinds of statements. The feature-gating
code is adjusted so that proc-macro attributes are still allowed on item
statements on stable.

Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be
adjusted to support being passed `Annotatable::Stmt`.
2020-11-26 17:08:35 -05:00
Jonas Schievink
6fcd589025
Rollup merge of #79000 - sivadeilra:user/ardavis/lev_distance, r=wesleywiser
Move lev_distance to rustc_ast, make non-generic

rustc_ast currently has a few dependencies on rustc_lexer. Ideally, an AST
would not have any dependency its lexer, for minimizing
design-time dependencies. Breaking this dependency would also have practical
benefits, since modifying rustc_lexer would not trigger a rebuild of rustc_ast.

This commit does not remove the rustc_ast --> rustc_lexer dependency,
but it does remove one of the sources of this dependency, which is the
code that handles fuzzy matching between symbol names for making suggestions
in diagnostics. Since that code depends only on Symbol, it is easy to move
it to rustc_span. It might even be best to move it to a separate crate,
since other tools such as Cargo use the same algorithm, and have simply
contain a duplicate of the code.

This changes the signature of find_best_match_for_name so that it is no
longer generic over its input. I checked the optimized binaries, and this
function was duplicated for nearly every call site, because most call sites
used short-lived iterator chains, generic over Map and such. But there's
no good reason for a function like this to be generic, since all it does
is immediately convert the generic input (the Iterator impl) to a concrete
Vec<Symbol>. This has all of the costs of generics (duplicated method bodies)
with no benefit.

Changing find_best_match_for_name to be non-generic removed about 10KB of
code from the optimized binary. I know it's a drop in the bucket, but we have
to start reducing binary size, and beginning to tame over-use of generics
is part of that.
2020-11-26 13:39:05 +01:00
b-naber
823dbb38e4 ast and parser 2020-11-25 19:55:41 +01:00
Aaron Hill
baefba80b7
Adjust pretty-print compat hack to work with item statements 2020-11-25 11:32:08 -05:00
Arlie Davis
5481c1bd6d Move lev_distance to rustc_ast, make non-generic
rustc_ast currently has a few dependencies on rustc_lexer. Ideally, an AST
would not have any dependency its lexer, for minimizing unnecessarily
design-time dependencies. Breaking this dependency would also have practical
benefits, since modifying rustc_lexer would not trigger a rebuild of rustc_ast.

This commit does not remove the rustc_ast --> rustc_lexer dependency,
but it does remove one of the sources of this dependency, which is the
code that handles fuzzy matching between symbol names for making suggestions
in diagnostics. Since that code depends only on Symbol, it is easy to move
it to rustc_span. It might even be best to move it to a separate crate,
since other tools such as Cargo use the same algorithm, and have simply
contain a duplicate of the code.

This changes the signature of find_best_match_for_name so that it is no
longer generic over its input. I checked the optimized binaries, and this
function was duplicated at nearly every call site, because most call sites
used short-lived iterator chains, generic over Map and such. But there's
no good reason for a function like this to be generic, since all it does
is immediately convert the generic input (the Iterator impl) to a concrete
Vec<Symbol>. This has all of the costs of generics (duplicated method bodies)
with no benefit.

Changing find_best_match_for_name to be non-generic removed about 10KB of
code from the optimized binary. I know it's a drop in the bucket, but we have
to start reducing binary size, and beginning to tame over-use of generics
is part of that.
2020-11-24 16:12:23 -08:00
Jonas Schievink
f66af28641
Rollup merge of #79016 - fanzier:underscore-expressions, r=petrochenkov
Make `_` an expression, to discard values in destructuring assignments

This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the third and final part of #71156, which was split up to allow for easier review.

With this PR, an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value, similarly to the wildcard `_` in patterns. For instance,
```rust
(a, _) = (1, 2)
```
will simply assign 1 to `a` and discard the 2. Note that for consistency,
```
_ = foo
```
is also allowed and equivalent to just `foo`.

Thanks to ````@varkor```` who helped with the implementation, particularly around pre-expansion gating.

r? ````@petrochenkov````
2020-11-15 13:39:48 +01:00
Fabian Zaiser
8cf3564310 Add underscore expressions for destructuring assignments
Co-authored-by: varkor <github@varkor.com>
2020-11-14 13:53:12 +00:00
Dániel Buga
a7f2bb6343 Reserve space in advance 2020-11-13 11:19:25 +01:00
Mara Bos
755dd14e00
Rollup merge of #78836 - fanzier:struct-and-slice-destructuring, r=petrochenkov
Implement destructuring assignment for structs and slices

This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.

Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.

This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).

Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.

Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.

r? ``@petrochenkov``
2020-11-12 19:46:09 +01:00
bors
5a6a41e784 Auto merge of #78782 - petrochenkov:nodoctok, r=Aaron1011
Do not collect tokens for doc comments

Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).

(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)

r? `@Aaron1011`
2020-11-12 00:33:55 +00:00
Fabian Zaiser
de84ad95b4 Implement destructuring assignment for structs and slices
Co-authored-by: varkor <github@varkor.com>
2020-11-11 12:10:52 +00:00
Nicholas-Baron
261ca04c92 Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.

A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.

The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
2020-11-10 20:07:47 -08:00
Dylan DPC
8ebca242bc
Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwco
rustc_ast: Do not panic by default when visiting macro calls

Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them.

The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
2020-11-09 19:06:55 +01:00
Vadim Petrochenkov
12de1e8985 Do not collect tokens for doc comments 2020-11-09 01:47:11 +03:00
bors
1773f60ea5 Auto merge of #78712 - petrochenkov:visitok, r=Aaron1011
rustc_ast: Visit tokens stored in AST nodes in mutable visitor

After #77271 token visiting is enabled only for one visitor in `rustc_expand\src\mbe\transcribe.rs` which applies hygiene marks to tokens produced by declarative macros (`macro_rules` or `macro`), so this change doesn't affect anything else.

When a macro has some interpolated token from an outer macro in its output
```rust
macro inner() {
    $interpolated
}
```
we can use the usual interpretation of interpolated tokens in token-based model - a None-delimited group - to write this macro in an equivalent form
```rust
macro inner() {
    ⟪ a b c d ⟫
}
```

When we are expanding the macro `inner` we need to apply hygiene marks to all tokens produced by it, including the tokens inside the group.

Before this PR we did this by visiting the AST piece inside the interpolated token and applying marks to all spans in it.
I'm not sure this is 100% correct (ideally we should apply the marks to tokens and then re-parse the AST from tokens), but it's a very good approximation at least.
We didn't however apply the marks to actual tokens stored in the nonterminal, so if we used the nonterminal as a token rather than as an AST piece (e.g. passed it to a proc macro), then we got hygiene bugs.
This PR applies the marks to tokens in addition to the AST pieces thus fixing the issue.

r? `@Aaron1011`
2020-11-08 20:00:51 +00:00
est31
dfa5e46fd5 The renumber pass is long gone
Originally, there has been a dedicated pass for renumbering
AST NodeIds to have actual values. This pass had been added by
commit a5ad4c3794.

Then, later, this step was moved to where it resides now,
macro expansion. See commit c86c8d41a2
or PR #36438.

The comment snippet, added by the original commit, has
survived the times without any change, becoming outdated
at removal of the dedicated pass.

Nowadays, grepping for the next_node_id function will show up
multiple places in the compiler that call it, but the main
rewriting that the comment talks about is still done in the
expansion step, inside an innocious looking visit_id function
that's called during macro invocation collection.
2020-11-06 03:18:01 +01:00
Vadim Petrochenkov
8def2fc122 rustc_ast: Never clone empty token streams in mutable visitor 2020-11-06 00:59:08 +03:00
Vadim Petrochenkov
1e15606547 rustc_ast: Visit tokens stored in AST nodes in mutable visitor 2020-11-06 00:30:52 +03:00
Matthias Krüger
bcd2f2df67 fix a couple of clippy warnings:
filter_next
manual_strip
redundant_static_lifetimes
single_char_pattern
unnecessary_cast
unused_unit
op_ref
redundant_closure
useless_conversion
2020-11-04 13:48:50 +01:00
Vadim Petrochenkov
90fafc8c8f rustc_ast: visit_mac -> visit_mac_call 2020-11-03 23:39:51 +03:00
Vadim Petrochenkov
3237b3886c rustc_ast: Do not panic by default when visiting macro calls 2020-11-03 20:38:20 +03:00
Yuki Okushi
0716724a0b
Rollup merge of #78376 - Aaron1011:feature/consistent-empty-expr, r=petrochenkov
Treat trailing semicolon as a statement in macro call

See #61733 (comment)

We now preserve the trailing semicolon in a macro invocation, even if
the macro expands to nothing. As a result, the following code no longer
compiles:

```rust
macro_rules! empty {
    () => { }
}

fn foo() -> bool { //~ ERROR mismatched
    { true } //~ ERROR mismatched
    empty!();
}
```

Previously, `{ true }` would be considered the trailing expression, even
though there's a semicolon in `empty!();`

This makes macro expansion more token-based.
2020-11-03 15:27:03 +09:00
Vadim Petrochenkov
19dbb02a89 Expand NtExpr tokens only in key-value attributes 2020-11-03 00:53:43 +03:00
Aaron Hill
e78e9d4a06
Treat trailing semicolon as a statement in macro call
See https://github.com/rust-lang/rust/issues/61733#issuecomment-716188981

We now preserve the trailing semicolon in a macro invocation, even if
the macro expands to nothing. As a result, the following code no longer
compiles:

```rust
macro_rules! empty {
    () => { }
}

fn foo() -> bool { //~ ERROR mismatched
    { true } //~ ERROR mismatched
    empty!();
}
```

Previously, `{ true }` would be considered the trailing expression, even
though there's a semicolon in `empty!();`

This makes macro expansion more token-based.
2020-11-02 13:03:13 -05:00
Vadim Petrochenkov
6b63e9b990 Do not remove tokens before AST json serialization 2020-11-01 00:03:35 +03:00
Vadim Petrochenkov
d0c63bccc5 parser: Cleanup LazyTokenStream and avoid some clones
by using a named struct instead of a closure.
2020-10-31 01:56:34 +03:00
bors
20b1e05a8d Auto merge of #77502 - varkor:const-generics-suggest-enclosing-braces, r=petrochenkov
Suggest that expressions that look like const generic arguments should be enclosed in brackets

I pulled out the changes for const expressions from https://github.com/rust-lang/rust/pull/71592 (without the trait object diagnostic changes) and made some small changes; the implementation is `@estebank's.`

We're also going to want to make some changes separately to account for trait objects (they result in poor diagnostics, as is evident from one of the test cases here), such as an adaption of https://github.com/rust-lang/rust/pull/72273.

Fixes https://github.com/rust-lang/rust/issues/70753.

r? `@petrochenkov`
2020-10-27 09:25:54 +00:00
varkor
ac1454001c Suggest expressions that look like const generic arguments should be enclosed in brackets
Co-Authored-By: Esteban Kuber <github@kuber.com.ar>
2020-10-26 21:54:45 +00:00
Yuki Okushi
0a26e4ba7e
Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkov
Split out statement attributes changes from #78306

This is the same as PR https://github.com/rust-lang/rust/pull/78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).

This shouldn't have any user-visible effects, so it can be landed without lang team discussion.

---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-25 18:43:49 +09:00
Aaron Hill
ac384ac2db
Fix inconsistencies in handling of inert attributes on statements
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-24 11:55:48 -04:00
Aaron Hill
b9b2546417
Unconditionally capture tokens for attributes.
This allows us to avoid synthesizing tokens in `prepend_attr`, since we
have the original tokens available.

We still need to synthesize tokens when expanding `cfg_attr`,
but this is an unavoidable consequence of the syntax of `cfg_attr` -
the user does not supply the `#` and `[]` tokens that a `cfg_attr`
expands to.
2020-10-21 18:57:29 -04:00
bors
22e6b9c689 Auto merge of #77250 - Aaron1011:feature/flat-token-collection, r=petrochenkov
Rewrite `collect_tokens` implementations to use a flattened buffer

Instead of trying to collect tokens at each depth, we 'flatten' the
stream as we go allong, pushing open/close delimiters to our buffer
just like regular tokens. One capturing is complete, we reconstruct a
nested `TokenTree::Delimited` structure, producing a normal
`TokenStream`.

The reconstructed `TokenStream` is not created immediately - instead, it is
produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This
closure stores a clone of the original `TokenCursor`, plus a record of the
number of calls to `next()/next_desugared()`. This is sufficient to reconstruct
the tokenstream seen by the callback without storing any additional state. If
the tokenstream is never used (e.g. when a captured `macro_rules!` argument is
never passed to a proc macro), we never actually create a `TokenStream`.

This implementation has a number of advantages over the previous one:

* It is significantly simpler, with no edge cases around capturing the
  start/end of a delimited group.

* It can be easily extended to allow replacing tokens an an arbitrary
  'depth' by just using `Vec::splice` at the proper position. This is
  important for PR #76130, which requires us to track information about
  attributes along with tokens.

* The lazy approach to `TokenStream` construction allows us to easily
  parse an AST struct, and then decide after the fact whether we need a
  `TokenStream`. This will be useful when we start collecting tokens for
  `Attribute` - we can discard the `LazyTokenStream` if the parsed
  attribute doesn't need tokens (e.g. is a builtin attribute).

The performance impact seems to be neglibile (see
https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a
small slowdown on a few benchmarks, but it only rises above 1% for incremental
builds, where it represents a larger fraction of the much smaller instruction
count. There a ~1% speedup on a few other incremental benchmarks - my guess is
that the speedups and slowdowns will usually cancel out in practice.
2020-10-21 15:03:14 +00:00
Aaron Hill
593fdd3d45
Rewrite collect_tokens implementations to use a flattened buffer
Instead of trying to collect tokens at each depth, we 'flatten' the
stream as we go allong, pushing open/close delimiters to our buffer
just like regular tokens. One capturing is complete, we reconstruct a
nested `TokenTree::Delimited` structure, producing a normal
`TokenStream`.

The reconstructed `TokenStream` is not created immediately - instead, it is
produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This
closure stores a clone of the original `TokenCursor`, plus a record of the
number of calls to `next()/next_desugared()`. This is sufficient to reconstruct
the tokenstream seen by the callback without storing any additional state. If
the tokenstream is never used (e.g. when a captured `macro_rules!` argument is
never passed to a proc macro), we never actually create a `TokenStream`.

This implementation has a number of advantages over the previous one:

* It is significantly simpler, with no edge cases around capturing the
  start/end of a delimited group.

* It can be easily extended to allow replacing tokens an an arbitrary
  'depth' by just using `Vec::splice` at the proper position. This is
  important for PR #76130, which requires us to track information about
  attributes along with tokens.

* The lazy approach to `TokenStream` construction allows us to easily
  parse an AST struct, and then decide after the fact whether we need a
  `TokenStream`. This will be useful when we start collecting tokens for
  `Attribute` - we can discard the `LazyTokenStream` if the parsed
  attribute doesn't need tokens (e.g. is a builtin attribute).

The performance impact seems to be neglibile (see
https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a
small slowdown on a few benchmarks, but it only rises above 1% for incremental
builds, where it represents a larger fraction of the much smaller instruction
count. There a ~1% speedup on a few other incremental benchmarks - my guess is
that the speedups and slowdowns will usually cancel out in practice.
2020-10-19 13:59:18 -04:00
Aaron Hill
f6aec82d4d
Avoid cloning the contents of a TokenStream in a few places 2020-10-19 12:30:41 -04:00
bors
834821e3b6 Auto merge of #78066 - bugadani:wat, r=jonas-schievink
Clean up small, surprising bits of code

This PR clean up a small number of unrelated, small things I found while browsing the code base.
2020-10-18 13:50:31 +00:00
Dániel Buga
d708d7fb79 No need to map the max_distance 2020-10-18 11:01:08 +02:00
Santiago Pastorino
03defb627c
Add check_generic_arg early pass 2020-10-16 17:14:36 -03:00
Santiago Pastorino
c3e8d7965c
Parse inline const expressions 2020-10-16 15:15:30 -03:00
Yuki Okushi
022d20759b
Rollup merge of #77739 - est31:remove_unused_code, r=petrochenkov,varkor
Remove unused code

Rustc has a builtin lint for detecting unused code inside a crate, but when an item is marked `pub`, the code, even if unused inside the entire workspace, is never marked as such. Therefore, I've built [warnalyzer](https://github.com/est31/warnalyzer) to detect unused items in a cross-crate setting.

Closes https://github.com/est31/warnalyzer/issues/2
2020-10-15 07:32:29 +09:00
est31
49d4a756f1 Remove unused code from rustc_ast 2020-10-14 04:14:32 +02:00
Aaron Hill
9a6ea38647
Add hack to keep actix-web and actori-web compiling
This extends the existing `ident_name_compatibility_hack` to handle the
`tuple_from_req` macro defined in `actix-web` (and its fork
`actori-web`).
2020-10-11 13:20:26 -04:00
Esteban Küber
4ae8f6ec7c address review comments 2020-10-09 22:00:48 -07:00
bors
91a79fb29a Auto merge of #76985 - hbina:clone_check, r=estebank
Prevent stack overflow in deeply nested types.

Related issue #75577 (?)

Unfortunately, I am unable to test whether this actually solves the problem because apparently, 12GB RAM + 2GB swap is not enough to compile the (admittedly toy) source file.
2020-10-07 21:51:12 +00:00
Robin Schoonover
5ab19676ed Remove extra indirection in LitKind::ByteStr 2020-10-04 15:52:15 -06:00
Erik Hofmayer
764967a7e5 tidy 2020-09-23 22:08:30 +02:00
Erik Hofmayer
138a2e5eaa /nightly/nightly-rustc 2020-09-23 21:51:56 +02:00
Erik Hofmayer
dd66ea2d3d Updated html_root_url for compiler crates 2020-09-23 21:14:43 +02:00
Dylan MacKenzie
6044836284 Add #![feature(const_fn_transmute)] to rustc_ast 2020-09-22 10:22:21 -07:00
Hanif Bin Ariffin
dc655b2842 Prevent stackoverflow 2020-09-21 04:20:41 +08:00
Ralf Jung
8405d50e12
Rollup merge of #76890 - matthiaskrgr:matches_simpl, r=lcnr
use matches!() macro for simple if let conditions
2020-09-20 15:52:01 +02:00
Matthias Krüger
40dddd3305 use matches!() macro for simple if let conditions 2020-09-18 20:28:35 +02:00
est31
ebdea01143 Remove redundant #![feature(...)] 's from compiler/ 2020-09-17 07:58:45 +02:00
bors
9b4154193e Auto merge of #76541 - matthiaskrgr:unstable_sort, r=davidtwco
use sort_unstable to sort primitive types

It's not important to retain original order if we have &[1, 1, 2, 3] for example.

clippy::stable_sort_primitive
2020-09-14 21:43:17 +00:00
Aaron Hill
fec0479075
Fully integrate token collection for additional AST structs
This commit contains miscellaneous changes that don't fit into any of
the other commits in this PR
2020-09-10 17:58:14 -04:00
Aaron Hill
156ef2bee8
Attach tokens to ast::Stmt
We currently only attach tokens when parsing a `:stmt` matcher for a
`macro_rules!` macro. Proc-macro attributes on statements are still
unstable, and need additional work.
2020-09-10 17:33:06 -04:00
Aaron Hill
c1011165e6
Attach TokenStream to ast::Visibility
A `Visibility` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
2020-09-10 17:33:06 -04:00
Aaron Hill
55082ce413
Attach TokenStream to ast::Path 2020-09-10 17:33:06 -04:00
Aaron Hill
3815e91ccd
Attach tokens to NtMeta (ast::AttrItem)
An `AttrItem` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
2020-09-10 17:33:06 -04:00
Aaron Hill
1823dea7df
Attach TokenStream to ast::Ty
A `Ty` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
2020-09-10 17:33:05 -04:00
Aaron Hill
de4bd9f0f8
Attach TokenStream to ast::Block
A `Block` does not have outer attributes, so we only capture tokens when
parsing a `macro_rules!` matcher
2020-09-10 17:33:05 -04:00
David Tolnay
fd4dd00dde
Syntactically permit unsafety on mods 2020-09-10 06:56:33 -07:00
bors
a18b34d979 Auto merge of #76291 - matklad:spacing, r=petrochenkov
Rename IsJoint -> Spacing

Builds on #76286 and might conflict with #76285

r? `@petrochenkov`
2020-09-10 08:07:48 +00:00
Tyler Mandry
fdff7defc9 Revert "Rollup merge of #76285 - matklad:censor-spacing, r=petrochenkov"
This reverts commit 85cee57fd7, reversing
changes made to b4d3873024.
2020-09-10 02:18:46 +00:00
Matthias Krüger
b4935e0726 use sort_unstable to sort primitive types
It's not important to retain original order if we have &[1, 1, 2, 3] for example.

clippy::stable_sort_primitive
2020-09-10 00:03:58 +02:00
Dylan DPC
6545985888
Rollup merge of #76274 - scottmcm:fix-76271, r=petrochenkov
Allow try blocks as the argument to return expressions

Fixes #76271

I don't think this needs to be edition-aware (phew) since `return try` in 2015 is also the start of an expression, just with a struct literal instead of a block (`return try { x: 4, y: 5 }`).
2020-09-07 01:17:46 +02:00
bors
ffaf158608 Auto merge of #76331 - Aaron1011:fix/group-compat-hack-test, r=petrochenkov
Account for version number in NtIdent hack

Issue #74616 tracks a backwards-compatibility hack for certain macros.
This has is implemented by hard-coding the filenames and macro names of
certain code that we want to continue to compile.

However, the initial implementation of the hack was based on the
directory structure when building the crate from its repository (e.g.
`js-sys/src/lib.rs`). When the crate is build as a dependency, it will
include a version number from the clone from the cargo registry (e.g.
`js-sys-0.3.17/src/lib.rs`), which would fail the check.

This commit modifies the backwards-compatibility hack to check that
desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the
proper part of the path.

See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646
for more details.
2020-09-06 06:15:28 +00:00
Aaron Hill
9e7ef659e1
Account for version number in NtIdent hack
Issue #74616 tracks a backwards-compatibility hack for certain macros.
This has is implemented by hard-coding the filenames and macro names of
certain code that we want to continue to compile.

However, the initial implementation of the hack was based on the
directory structure when building the crate from its repository (e.g.
`js-sys/src/lib.rs`). When the crate is build as a dependency, it will
include a version number from the clone from the cargo registry (e.g.
`js-sys-0.3.17/src/lib.rs`), which would fail the check.

This commit modifies the backwards-compatibility hack to check that
desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the
proper part of the path.

See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646
for more details.
2020-09-04 13:10:23 -04:00
Aleksey Kladov
09d3db2e59 Optimize Cursor::look_ahead
Cloning a tt is cheap, but not free (there's Arc inside).
2020-09-03 23:28:22 +02:00
Aleksey Kladov
ccf41dd5eb Rename IsJoint -> Spacing
To match better naming from proc-macro
2020-09-03 17:32:45 +02:00
Scott McMurray
791f93c796 Allow try blocks as the argument to return expressions
Fixes 76271
2020-09-02 23:39:50 -07:00
bors
b4acb11033 Auto merge of #76170 - matklad:notrivia, r=petrochenkov
Remove trivia tokens

r? @ghost
2020-09-02 03:19:38 +00:00
Aleksey Kladov
5326361fc0 Remove trivia tokens 2020-09-01 11:39:11 +02:00
Aaron Hill
090b16717a
Factor out StmtKind::MacCall fields into MacCallStmt struct
In PR #76130, I add a fourth field, which makes using a tuple variant
somewhat unwieldy.
2020-08-30 18:38:53 -04:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00