Commit Graph

233 Commits

Author SHA1 Message Date
Vadim Petrochenkov
6655727041 rustc_feature: Convert BuiltinAttribute from tuple to a struct 2021-11-12 20:15:14 +08:00
bors
46b8e7488e Auto merge of - matthiaskrgr:clippy_nov7, r=jyn514
more clippy fixes
2021-11-07 20:04:54 +00:00
Matthias Krüger
5c454551da more clippy fixes 2021-11-07 16:59:05 +01:00
Vadim Petrochenkov
2834f57c45 ast: Fix naming conventions in AST structures
TraitKind -> Trait
TyAliasKind -> TyAlias
ImplKind -> Impl
FnKind -> Fn

All `*Kind`s in AST are supposed to be enums.

Tuple structs are converted to braced structs for the types above, and fields are reordered in syntactic order.

Also, mutable AST visitor now correctly visit spans in defaultness, unsafety, impl polarity and constness.
2021-11-07 21:38:17 +08:00
Mark Rousskov
3215eeb99f
Revert "Add rustc lint, warning when iterating over hashmaps" 2021-10-28 11:01:42 -04:00
Matthias Krüger
87822b27ee
Rollup merge of - lcnr:query-stable-lint, r=estebank
Add rustc lint, warning when iterating over hashmaps

r? rust-lang/wg-incr-comp
2021-10-24 15:48:42 +02:00
r00ster91
3c1d55422a Some "parenthesis" and "parentheses" fixes 2021-10-17 12:04:01 +02:00
lcnr
00e5abe9b6 allow potential_query_instability everywhere 2021-10-15 10:58:18 +02:00
Mark Rousskov
8485e6fdec Revert "Stabilize arbitrary_enum_discriminant"
This reverts commit 7a62f29f31.
2021-10-14 10:57:56 -04:00
Wim Looman
18fdd816b7 Allow adding a set of cfg's to hide from being implicitly doc(cfg)'d
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg
 #[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly
treated as a doc(cfg) to render a message in the documentation.
2021-10-05 18:04:15 +02:00
Jubilee
c9158db1f3
Rollup merge of - FabianWolff:issue-84075, r=davidtwco
Deny `where` clauses on `auto` traits

Fixes .
2021-10-04 21:12:43 -07:00
Fabian Wolff
e34fd54611 Deny where clauses on auto traits 2021-10-03 18:06:21 +02:00
Hirochika Matsumoto
3818981ca1 Practice diagnostic message convention 2021-10-03 16:16:28 +09:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
Vishad Goyal
9f7e281d47 delay error for enabling unstable lib features
If #![feature] is used outside the nightly channel for only lib
features, the check will be delayed to the stability pass after
parsing. This is done so that appropriate help messages can be shown if
the #![feature] has been used needlessly
2021-09-16 14:22:32 -04:00
Manish Goregaokar
fb2d7dff80
Rollup merge of - pnkfelix:revert-anon-union-parsing, r=davidtwco
Revert anon union parsing

Revert PR  and , which implemented anonymous union parsing in a manner that broke the context-sensitivity for the `union` keyword and thus broke stable Rust code.

Fix .
2021-09-15 14:56:58 -07:00
bors
cdeba02ff7 Auto merge of - fee1-dead:const-drop, r=oli-obk
Const drop

The changes are pretty primitive at this point. But at least it works. ^-^

Problems with the current change that I can think of now:
 - [x] `~const Drop` shouldn't change anything in the non-const world.
 - [x] types that do not have drop glues shouldn't fail to satisfy `~const Drop` in const contexts. `struct S { a: u8, b: u16 }` This might not fail for `needs_non_const_drop`, but it will fail in `rustc_trait_selection`.
 - [x] The current change accepts types that have `const Drop` impls but have non-const `Drop` glue.

Fixes .

Significant Changes:

- `~const Drop` is no longer treated as a normal trait bound. In non-const contexts, this bound has no effect, but in const contexts, this restricts the input type and all of its transitive fields to either a) have a `const Drop` impl or b) can be trivially dropped (i.e. no drop glue)
- `T: ~const Drop` will not be linted like `T: Drop`.
- Instead of recursing and iterating through the type in `rustc_mir::transform::check_consts`, we use the trait system to special case `~const Drop`. See [`rustc_trait_selection::...::candidate_assembly#assemble_const_drop_candidates`](https://github.com/fee1-dead/rust/blob/const-drop/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L817) and others.

Changes not related to `const Drop`ping and/or changes that are insignificant:

 - `Node.constness_for_typeck` no longer returns `hir::Constness::Const` for type aliases in traits. This was previously used to hack how we determine default bound constness for items. But because we now use an explicit opt-in, it is no longer needed.
 - Removed `is_const_impl_raw` query. We have `impl_constness`, and the only existing use of that query uses `HirId`, which means we can just operate it with hir.
 - `ty::Destructor` now has a field `constness`, which represents the constness of the destructor.

r? `@oli-obk`
2021-09-15 03:51:03 +00:00
Jubilee
746eb1d84d
Rollup merge of - Noble-Mushtak:88577, r=estebank
Fix ICE for functions with more than 65535 arguments

This pull request fixes  by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32`, thus allowing for more than 65,535 arguments in a function. Note that I also added a regression test, but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.
2021-09-11 08:23:41 -07:00
Felix S. Klock II
91feb76d13 Revert "Implement Anonymous{Struct, Union} in the AST"
This reverts commit 059b68dd67.

Note that this was manually adjusted to retain some of the refactoring
introduced by commit 059b68dd67, so that it could
likewise retain the correction introduced in commit
5b4bc05fa5
2021-09-09 09:14:17 -04:00
Felix S. Klock II
b6aa7e3105 Manually crafted revert of d4ad050ce5 . 2021-09-09 09:14:17 -04:00
Deadbeef
f749e05f6b
Allow ~const bounds on inherent impls 2021-09-09 05:21:33 +00:00
Noble-Mushtak
804ccfaaab Fatal error for functions with more than 65535 arguments 2021-09-08 21:14:49 -04:00
Mark Rousskov
b4e7649d6d Bump stage0 compiler to 1.56 2021-09-08 20:51:05 -04:00
bors
b27ccbc7e1 Auto merge of - cjgillot:abilint, r=estebank
Lint missing Abi in ast validation instead of lowering.
2021-09-02 06:06:24 +00:00
Camille GILLOT
8d7d488d3b Lint Abi in ast validation. 2021-08-31 20:30:17 +02:00
Mara Bos
ab37e49611
Rollup merge of - fee1-dead:trait-assoc-tilde-const, r=oli-obk
Allow `~const` bounds on trait assoc functions

r? `@oli-obk`
2021-08-31 17:54:56 +02:00
lcnr
4747cbb3bb allow unordered const/ty params if any cg feature is active 2021-08-30 11:00:21 +02:00
lcnr
0c28e028b6 feature(const_generics) -> feature(const_param_types) 2021-08-30 11:00:21 +02:00
Deadbeef
523490e94a
Allow ~const bounds on trait assoc functions 2021-08-28 08:03:16 +00:00
Deadbeef
1164c946b0
Fix visiting twice 2021-08-27 05:07:37 +00:00
Deadbeef
8660832086
Introduce ~const
- [x] Removed `?const` and change uses of `?const`
 - [x] Added `~const` to the AST. It is gated behind const_trait_impl.
 - [x] Validate `~const` in ast_validation.
 - [ ] Add enum `BoundConstness` to the HIR. (With variants `NotConst` and
 `ConstIfConst` allowing future extensions)
 - [ ] Adjust trait selection and pre-existing code to use `BoundConstness`.
 - [ ] Optional steps (*for this PR, obviously*)
      - [ ] Fix 
      - [ ] Do something with constness bounds in chalk
2021-08-27 05:07:37 +00:00
Aaron Hill
af46699f81
Remove Session.used_attrs and move logic to CheckAttrVisitor
Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).

`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`

Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.

We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.

With this commit, a large source of global untracked state is removed.
2021-08-21 13:27:27 -05:00
bors
02b27f1e70 Auto merge of - fee1-dead:stabilize, r=LeSeulArtichaut
Stabilize `arbitrary_enum_discriminant`

Closes .

----

## Stabilization Report

_copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_

### Summary

Enables a user to specify *explicit* discriminants on arbitrary enums.

Previously, this was hard to achieve:

```rust
#[repr(u8)]
enum Foo {
    A(u8) = 0,
    B(i8) = 1,
    C(bool) = 42,
}
```

Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants.

In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md), this feature would provide more flexibility for FFI and unsafe code involving enums.

### Test cases

Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant), there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete).

### Edge cases

The feature is well defined and does not have many edge cases.
One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved.

### Previous PRs

The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book, https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639.

### Resolution of unresolved questions

The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271.

----

(someone please add `needs-fcp`)
2021-08-18 01:00:17 +00:00
Caio
6aa9937a76 Introduce hir::ExprKind::Let - Take 2 2021-08-15 16:18:26 -03:00
hyd-dev
0bb2ea653e
Adjust #[no_mangle]-related checks and lints for impl items 2021-08-12 17:11:44 +08:00
bjorn3
a501308ec1 Replace #[plugin_registrar] with exporting __rustc_plugin_registrar 2021-08-10 14:20:48 +02:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
Deadbeef
7a62f29f31
Stabilize arbitrary_enum_discriminant 2021-07-28 18:08:34 +08:00
Yuki Okushi
23479f716a
Rollup merge of - spastorino:remove-min-tait, r=oli-obk
Remove min_type_alias_impl_trait in favor of type_alias_impl_trait

r? ``@oli-obk``
2021-07-28 18:28:19 +09:00
Santiago Pastorino
38bdd0e019
Make all tests use type_alias_impl_trait feature instead of min 2021-07-27 12:33:02 -03:00
bors
998cfe5aad Auto merge of - MarcusDunn:master, r=pnkfelix
Stabilize bindings_after_at

attempting to stabilze bindings_after_at [](https://github.com/rust-lang/rust/issues/65490), im pretty new to the whole thing so any pointers are greatly appreciated.
2021-07-27 05:53:31 +00:00
bors
0d76b73745 Auto merge of - workingjubilee:stable-rangefrom-pat, r=joshtriplett
Stabilize "RangeFrom" patterns in 1.55

Implements a partial stabilization of  and .
Reference PR: https://github.com/rust-lang/reference/pull/900

# Stabilization Report

This stabilizes the `X..` pattern, shown as such, offering an exhaustive match for unsigned integers:
```rust
match x as u32 {
      0 => println!("zero!"),
      1.. => println!("positive number!"),
}
```

Currently if a Rust author wants to write such a match on an integer, they must use `1..={integer}::MAX` . By allowing a "RangeFrom" style pattern, this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match, allowing for easier refactoring. This is particularly useful for instances like the above case, where different behavior on "0" vs. "1 or any positive number" is desired, and the actual MAX is unimportant.

Notably, this excepts slice patterns which include half-open ranges from stabilization, as the wisdom of those is still subject to some debate.

## Practical Applications

Instances of this specific usage have appeared in the compiler:
16143d1067/compiler/rustc_middle/src/ty/inhabitedness/mod.rs (L219)
673d0db5e3/compiler/rustc_ty_utils/src/ty.rs (L524)

And I have noticed there are also a handful of "in the wild" users who have deployed it to similar effect, especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match, as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](05e5db00d5/WebAssembly/scale_std/src/fixed_point.rs (L685-L695)).

## Tests
There were already many tests in [src/test/ui/half-open-range/patterns](90a2e5e3fe/src/test/ui/half-open-range-patterns), as well as [generic pattern tests that test the `exclusive_range_pattern` feature](673d0db5e3/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs), many dating back to the feature's introduction and remaining standing to this day. However, this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is, at least, a mild diagnostic improvement in some edge cases, because before now, the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag, while also emitting the "inclusive range with no end" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of, so removing the flag request is a strict improvement. The arrival of the `J | K` "or" pattern also enables some odd formations.

Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example, linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692, which may be useful to reference to observe the current behavior more closely.

In addition tests constituting an explanation of the "slicing range patterns" syntax issue are included in this PR.

## Desiderata

The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors, as they make some patterns much more natural to write, but there is disagreement regarding the "closed" exclusive range pattern or the "RangeTo" pattern, especially where it creates "off by one" gaps in the presence of a "catch-all" wildcard case. Also, there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on, ideally, and I think it would be reasonable to consider such a blocker to stabilizing this feature, but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the "point" of the feature, at least from my view, is to make it easier to omit wildcard matches: a pattern with such an "open" match produces an irrefutable match and does not need the wild card case, making it easier to benefit from exhaustiveness checking.

## History

- Implemented:
  - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712
  - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258
- Unresolved Questions:
  - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles, given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656, but it is still unknown what changes might be desired
  - How we want to handle slice patterns in ranges seems to be an open question still, as witnessed in the discussion of this PR!

I checked but I couldn't actually find an RFC for this, and given "approved provisionally by lang team without an RFC", I believe this might require an RFC before it can land? Unsure of procedure here, on account of this being stabilizing a subset of a feature of syntax.

r? `@scottmcm`
2021-07-11 06:31:42 +00:00
bors
cb3c4ee718 Auto merge of - FabianWolff:issue-86053, r=davidtwco
Handle C-variadic arguments properly when reporting region errors

This pull request fixes . The issue is that for a C-variadic function
```rust
#![feature(c_variadic)]
unsafe extern "C" fn foo(_: (), ...) {}
```
`foo`'s signature will contain only the first parameter (and have `c_variadic` set to `true`), whereas its body has a second argument (a `hir::Pat` for the `...`).

The code for reporting region errors iterates over the body's parameters and tries to fetch the corresponding parameter from the signature; this causes an out-of-bounds ICE for the `...` (though not in the example above, because there are no region errors to report).

I have simply restricted the iteration over the body parameters to exclude `...`, which is fine because `...` cannot cause a region error.
2021-06-17 06:34:12 +00:00
klensy
6a19867417 simplify validate_generic_param_order 2021-06-13 01:39:57 +03:00
Yuki Okushi
3b47d337e0
Rollup merge of - BoxyUwU:const-param-default-diagnostics, r=oli-obk
Fix some diagnostic issues with const_generics_defaults feature gate

This PR makes a few changes:
- print out const param defaults in "lifetime ordering" errors rather than discarding them
- update `is_simple_text` to account for const params when checking if a type has no generics, this was causing a note to be failed to add to an error message
- fixes some diagnostic wording that incorrectly said there was ordering restrictions between type/const params despite the `const_generics_defaults` feature gate is active
2021-06-12 01:15:56 +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
Fabian Wolff
7dccce0706 Handle C-variadic arguments properly when reporting region errors 2021-06-09 17:02:39 +02:00
marcusdunn
a11c8e7ff3 replaced feature-gate use with cfg_attr 2021-06-04 09:42:50 -07:00
Joshua Nelson
15fec1fb80 Remove doc(include) 2021-06-04 08:05:54 -04:00
Jubilee Young
43bad44ff0 Reestablish feature gate for RangeFrom in slices 2021-06-03 20:49:33 -07:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
Ellen
f208f207d6 Make lifetime ordering error pretty print const param defaults 2021-05-29 03:54:32 +01:00
Joshua Nelson
e48b6b4599 Stabilize extended_key_value_attributes
# Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")

This has been available on nightly since 1.50 with no major issues.

 ## Notes

 ### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

 ### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

 ## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- https://github.com/rust-lang/rust/pull/83329
- https://github.com/rust-lang/rust/pull/83230
- https://github.com/rust-lang/rust/pull/82641
- https://github.com/rust-lang/rust/pull/80534

 ## Implementation history

- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563

 ## Unresolved Questions

~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.
2021-05-18 01:01:36 -04:00
jedel1043
d4ad050ce5 Check and deny anonymous fields on ast_validation 2021-05-16 09:51:00 -05: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
Luqman Aden
db555e1284 Implement RFC 2951: Native link modifiers
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
2021-05-05 16:04:25 -07:00
bors
855c2d130f Auto merge of - spastorino:revert-pub-macro-rules, r=nikomatsakis
Revert "Rollup merge of  - spastorino:pubrules, r=nikomatsakis"

This reverts commit e2561c58a4, reversing
changes made to 2982ba50fc.

As discussed in  this feature is not complete and in particular doesn't work cross macros and given that this is not going to be included in edition 2021 nobody seems to be trying to fix the underlying problem. When can add this again I guess, whenever somebody has the time to make it work cross crates.

r? `@nikomatsakis`
2021-04-28 05:52:47 +00:00
bors
ee8382f297 Auto merge of - RalfJung:const_fn_in_trait, r=oli-obk
Always reject `const fn` in `trait` during parsing.

'const fn' in trait are rejected in the AST:
b78c0d8a4d/compiler/rustc_ast_passes/src/ast_validation.rs (L1411)
So this feature gate check is a NOP and we can just remove it.

The src/test/ui/feature-gates/feature-gate-min_const_fn.rs and src/test/ui/feature-gates/feature-gate-const_fn.rs tests ensure that we still reject `const fn` in `trait`

Cc https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`
2021-04-26 02:56:25 +00:00
bors
58bdb08947 Auto merge of - lcnr:const-generics-defaults-name-res, r=varkor
various const parameter defaults improvements

Actually resolve names in const parameter defaults, fixing `struct Foo<const N: usize = { usize::MAX }>`.

---
Split generic parameter ban rib for types and consts, allowing
```rust
#![feature(const_generics_defaults)]
struct Q;
struct Foo<T = Q, const Q: usize = 3>(T);
```

---
Remove the type/const ordering restriction if `const_generics_defaults` is active, even if `const_generics` is not. allowing us to stabilize and test const param defaults separately.

---
Check well formedness of const parameter defaults, eagerly emitting an error for `struct Foo<const N: usize = { 0 - 1 }>`

---
Do not forbid const parameters in param defaults, allowing `struct Foo<const N: usize, T = [u8; N]>(T)` and `struct Foo<const N: usize, const M: usize = N>`. Note that this should not change anything which is stabilized, as on stable, type parameters must be in front of const parameters, which means that type parameter defaults are only allowed if no const parameters exist.

We still forbid generic parameters inside of const param types.

r? `@varkor` `@petrochenkov`
2021-04-25 14:00:49 +00:00
Ralf Jung
75bab0782a 'const fn' in trait are rejected in the AST, this feature gate check is a NOP 2021-04-25 11:03:03 +02:00
bors
a7aba58e96 Auto merge of - jyn514:stable-help, r=estebank
On stable, suggest removing `#![feature]` for features that have been stabilized

I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the
appropriate help with `channel = "beta"`:

```
error[E0554]: `#![feature]` may not be used on the beta release channel
 --> src/lib.rs:2:1
  |
2 | #![feature(min_const_generics)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute
  |
  = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable

error[E0554]: `#![feature]` may not be used on the beta release channel
 --> src/lib.rs:3:1
  |
3 | #![feature(min_const_generics, min_specialization)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable

error[E0554]: `#![feature]` may not be used on the beta release channel
 --> src/lib.rs:4:1
  |
4 | #![feature(box_patterns)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^
```

Closes https://github.com/rust-lang/rust/issues/83715.
2021-04-24 02:25:54 +00:00
Santiago Pastorino
0e4d2fd447
Revert "Rollup merge of - spastorino:pubrules, r=nikomatsakis"
This reverts commit e2561c58a4, reversing
changes made to 2982ba50fc.
2021-04-23 10:40:32 -03:00
Jack Huey
b78c0d8a4d Review comments 2021-04-21 11:49:59 -04:00
lcnr
7cb1dcd488 loosen ordering restricts for const_generics_defaults 2021-04-21 15:25:58 +02:00
Jack Huey
4568e7d62e Move nested quantification check to ast_validation 2021-04-21 03:12:04 -04:00
bors
c4ba8e3e5f Auto merge of - 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
Charles Lew
fc357039f9 Remove #[main] attribute. 2021-04-16 13:04:02 +08:00
Alex Crichton
482a3d06c3 rustc: Add a new wasm ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-08 08:03:18 -07:00
Charles Lew
e5f9271f36 Stablize non_ascii_idents feature. 2021-04-08 02:52:00 +08:00
Charles Lew
4752a54ad0 Disable using non-ascii identifiers in extern blocks. 2021-04-07 09:56:50 +08:00
Jubilee Young
91bc117e53 Allow exclusive range-from patterns 2021-04-05 22:02:18 -07:00
Joshua Nelson
53a1105074 On stable, suggest removing #![feature] for features that have been stabilized
I don't know how to test this. I confirmed locally that this gives the
appropriate help with `channel = "beta"`:

```
error[E0554]: `#![feature]` may not be used on the beta release channel
 --> src/lib.rs:2:1
  |
2 | #![feature(min_const_generics)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute
  |
  = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable

error[E0554]: `#![feature]` may not be used on the beta release channel
 --> src/lib.rs:3:1
  |
3 | #![feature(min_const_generics, min_specialization)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable

error[E0554]: `#![feature]` may not be used on the beta release channel
 --> src/lib.rs:4:1
  |
4 | #![feature(box_patterns)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^
```
2021-04-02 19:36:44 -04:00
bors
5662d9343f Auto merge of - camelid:rename-doc-spotlight, r=jyn514
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`

Fixes .

"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation

r? `@Manishearth`
2021-04-02 07:04:58 +00:00
lcnr
b0feb5be2f progress, stuff compiles now 2021-03-23 17:16:20 +00:00
varkor
8ef81388e2 Some refactoring 2021-03-23 17:16:20 +00:00
kadmin
e4e5db4e42 Add has_default to GenericParamDefKind::Const
This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults

Update const_generics:default locations

Previously just ignored them, now actually do something about them.

Fix using type check instead of value

Add parsing

This adds all the necessary changes to lower const-generics defaults from parsing.

Change P<Expr> to AnonConst

This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.

Attempt to fix lowering bugs
2021-03-23 17:16:20 +00:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05: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
Camelid
34c6cee397 Rename #[doc(spotlight)] to #[doc(notable_trait)]
"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation
2021-03-15 13:59:54 -07:00
Oli Scherer
1f7df1956a Replace type_alias_impl_trait by min_type_alias_impl_trait with no actual changes in behaviour
This makes `type_alias_impl_trait` not actually do anything anymore
2021-03-15 17:32:43 +00:00
katelyn a. martin
df45c579de rustc_target: add "unwind" payloads to Abi
### Overview

    This commit begins the implementation work for RFC 2945. For more
    information, see the rendered RFC [1] and tracking issue [2].

    A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
    and `Thiscall` variants, marking whether unwinding across FFI
    boundaries is acceptable. The cases where each of these variants'
    `unwind` member is true correspond with the `C-unwind`,
    `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
    introduced in RFC 2945 [3].

 ### Feature Gate and Unstable Book

    This commit adds a `c_unwind` feature gate for the new ABI strings.
    Tests for this feature gate are included in `src/test/ui/c-unwind/`,
    which ensure that this feature gate works correctly for each of the
    new ABIs.

    A new language features entry in the unstable book is added as well.

 ### Further Work To Be Done

    This commit does not proceed to implement the new unwinding ABIs,
    and is intentionally scoped specifically to *defining* the ABIs and
    their feature flag.

 ### One Note on Test Churn

    This will lead to some test churn, in re-blessing hash tests, as the
    deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
    because we can no longer guarantee the ordering of the `Abi`
    variants.

    While this is a downside, this decision was made bearing in mind
    that RFC 2945 states the following, in the "Other `unwind` Strings"
    section [3]:

    >  More unwind variants of existing ABI strings may be introduced,
    >  with the same semantics, without an additional RFC.

    Adding a new variant for each of these cases, rather than specifying
    a payload for a given ABI, would quickly become untenable, and make
    working with the `Abi` enum prone to mistakes.

    This approach encodes the unwinding information *into* a given ABI,
    to account for the future possibility of other `-unwind` ABI
    strings.

 ### Ignore Directives

    `ignore-*` directives are used in two of our `*-unwind` ABI test
    cases.

    Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
    ignore architectures that do not support `stdcall` and
    `thiscall`, respectively.

    These directives are cribbed from
    `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
    `src/test/ui/extern/extern-thiscall.rs` for `thiscall`.

    This would otherwise fail on some targets, see:
    fcf697f902

 ### Footnotes

[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
2021-03-09 14:38:29 -05:00
Esteban Küber
63fb294a74 Add help for matches for if let in arm guard 2021-03-07 14:44:21 -08:00
Esteban Küber
23bcea4249 Add help suggesting matches to let_chains lint 2021-03-07 14:17:10 -08:00
Dylan DPC
e2561c58a4
Rollup merge of - spastorino:pubrules, r=nikomatsakis
Support `pub` on `macro_rules`

This rebases and updates `since` version of  from ``@petrochenkov``

r? ``@nikomatsakis``
2021-02-23 16:10:23 +01:00
Vadim Petrochenkov
0fddc2f780
Support pub on macro_rules 2021-02-19 13:52:57 -03: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
b593389edb Auto merge of - hug-dev:nonsecure-call-abi, r=jonas-schievink
Add a new ABI to support cmse_nonsecure_call

This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call.

See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928).

This is a followup to  which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃
I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now).

On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
2021-02-03 06:00:43 +00:00
Hugues de Valon
ce9818f2b7 Add a new ABI to support cmse_nonsecure_call
This commit adds a new ABI to be selected via `extern
"C-cmse-nonsecure-call"` on function pointers in order for the compiler to
apply the corresponding cmse_nonsecure_call callsite attribute.
For Armv8-M targets supporting TrustZone-M, this will perform a
non-secure function call by saving, clearing and calling a non-secure
function pointer using the BLXNS instruction.

See the page on the unstable book for details.

Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2021-02-02 13:04:31 +00:00
Dániel Buga
b87e1ecdf0 Box the biggest ast::ItemKind variants 2021-02-01 09:23:39 +01:00
LingMan
a56bffb4f9 Use Option::map_or instead of .map(..).unwrap_or(..) 2021-01-14 19:23:59 +01:00
bors
467f5e99a5 Auto merge of - rokob:iss76011, r=estebank
Suggest async {} for async || {}

Fixes 

This adds support for adding help diagnostics to the feature gating checks and
then uses it for the async_closure gate to add the extra bit of help
information as described in the issue.
2021-01-12 02:56:51 +00:00
bors
c97f11af7b Auto merge of - sasurau4:feature/add-suggestion-for-pattern-in-fns-without-body, r=matthewjasper
Add suggestion for PATTERNS_IN_FNS_WITHOUT_BODY

## Overview

Fix 
2021-01-10 20:48:27 +00: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
Rémy Rakic
942b7ce2c1 make const_generics_defaults use the unstable syntax mechanism
This is important to not accidentally stabilize the parsing of the syntax while it still is experimental and not formally accepted
2021-01-01 11:01:01 +01:00
Rémy Rakic
1fc3c4c16d adjust const generics defaults FIXMEs to the new feature gate 2021-01-01 11:01:01 +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
Dylan DPC
1f431f9066
Rollup merge of - max-heller:issue-80512-fix, r=varkor
Take type defaults into account in suggestions to reorder generic parameters

Fixes 
2020-12-31 22:20:53 +01:00
max-heller
947b279bc6 Take type defaults into account in suggestions to reorder generic parameters 2020-12-30 16:00:25 -05:00
Mara Bos
9e8edc8c22
Rollup merge of - jyn514:rename-empty, r=petrochenkov
Rename kw::Invalid -> kw::Empty

See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.

r? `@petrochenkov`
2020-12-30 20:56:58 +00:00
Joshua Nelson
edeac1778c Rename kw::Invalid -> kw::Empty
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.
2020-12-30 09:50:02 -05:00
LingMan
3dae414cb6 Use Option::map_or instead of open coding it 2020-12-29 04:27:37 +01:00
Bastian Kauschke
06cc9c26da stabilize min_const_generics 2020-12-26 18:24:10 +01:00
Daiki Ihara
acbebd81d4 add suggest for PatternsInWithoutBody 2020-12-21 21:40:47 +09:00
LeSeulArtichaut
46e9212ecb Change the message for if_let_guard feature gate 2020-12-17 17:08:18 +01:00
Tyler Mandry
dc90573454
Rollup merge of - camelid:better-error-for-default-fn, r=davidtwco
Clarify the 'default is only allowed on...' error

Code like

    impl Foo {
        default fn foo() {}
    }

will trigger the error

    error: `default` is only allowed on items in `impl` definitions
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this

but that's very confusing! I *did* put it on an item in an impl!

So this commit changes the message to

    error: `default` is only allowed on items in trait impls
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this
2020-12-10 21:33:10 -08:00
Vadim Petrochenkov
31d72c2658 Accept arbitrary expressions in key-value attributes at parse time 2020-12-09 21:37:32 +03:00
Camelid
4e21942ba4 Clarify the 'default is only allowed on...' error
Code like

    impl Foo {
        default fn foo() {}
    }

will trigger the error

    error: `default` is only allowed on items in `impl` definitions
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this

but that's very confusing! I *did* put it on an item in an impl!

So this commit changes the message to

    error: `default` is only allowed on items in trait impls
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this
2020-12-08 21:56:22 -08:00
bors
4ae328bef4 Auto merge of - 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
Aaron Hill
92bfa05b07
Bump recursion_limit in rustc_ast_passes
When cfg(parallel_compiler) is enabled, we end up trying to prove
Send/Sync bounds for some deeply nested types (at least when rustdoc is
run).
2020-11-27 15:47:58 -05:00
bors
cfed9184f4 Auto merge of - 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
b-naber
823dbb38e4 ast and parser 2020-11-25 19:55:41 +01:00
Camelid
810324d1f3 Rename optin_builtin_traits to auto_traits
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.

There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.

Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
2020-11-23 14:14:06 -08:00
ThePuzzlemaker
92aa0e6295
Use span_suggestion_verbose instead of span_suggestion for fn with qualifiers inside an extern "C" block 2020-11-17 07:57:54 -06: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
Mara Bos
755dd14e00
Rollup merge of - 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: ). This PR is the second part of , which was split up to allow for easier review.

Note that the first PR () 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 . 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
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
Jonas Schievink
105f4b8792
Rollup merge of - petrochenkov:cleantarg, r=Mark-Simulacrum
rustc_target: Further cleanup use of target options

Follow up to https://github.com/rust-lang/rust/pull/77729.

Implements items 2 and 4 from the list in https://github.com/rust-lang/rust/pull/77729#issue-500228243.

The first commit collapses uses of `target.options.foo` into `target.foo`.

The second commit renames some target options to avoid tautology:
`target.target_endian` -> `target.endian`
`target.target_c_int_width` -> `target.c_int_width`
`target.target_os` -> `target.os`
`target.target_env` -> `target.env`
`target.target_vendor` -> `target.vendor`
`target.target_family` -> `target.os_family`
`target.target_mcount` -> `target.mcount`

r? `@Mark-Simulacrum`
2020-11-10 14:45:21 +01:00
Vadim Petrochenkov
bf66988aa1 Collapse all uses of target.options.foo into target.foo
with an eye on merging `TargetOptions` into `Target`.

`TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-08 17:29:13 +03: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
Dániel Buga
3fba948510 Fix typos 2020-10-29 16:51:46 +01:00
Santiago Pastorino
66e254314d
Lower inline const's AST to HIR 2020-10-16 15:21:16 -03:00
Santiago Pastorino
3c4ad55082
Add inline_const feature flag 2020-10-16 15:13:28 -03:00
est31
4fa5578774 Replace target.target with target and target.ptr_width with target.pointer_width
Preparation for a subsequent change that replaces
rustc_target::config::Config with its wrapped Target.

On its own, this commit breaks the build. I don't like making
build-breaking commits, but in this instance I believe that it
makes review easier, as the "real" changes of this PR can be
seen much more easily.

Result of running:

find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \;
./x.py fmt
2020-10-15 12:02:24 +02:00
Andy Weiss
5b475a4618 Suggest async {} for async || {}
Fixes 

This adds support for adding help diagnostics to the feature gating checks and
then uses it for the async_closure gate to add the extra bit of help
information as described in the issue.
2020-09-22 13:22:10 -07:00
Matthias Krüger
40dddd3305 use matches!() macro for simple if let conditions 2020-09-18 20:28:35 +02:00
Guillaume Gomez
d069c7e928 Stabilize doc_alias feature 2020-09-14 11:03:47 +02:00
Andreas Jonson
b8752fff19 update the version of itertools and parking_lot
this is to avoid compiling multiple version of the crates in rustc
2020-09-12 08:26:53 +02: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
David Tolnay
fd4dd00dde
Syntactically permit unsafety on mods 2020-09-10 06:56:33 -07:00
Amjad Alsharafi
8f2d9069a8 Implementation of incompatible features error
If two features are defined as incompatible, using them together would
result in an error
2020-09-04 22:17:28 +08:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00