about summary refs log tree commit diff
path: root/src/libsyntax/feature_gate
AgeCommit message (Collapse)AuthorLines
2019-10-24pre-expansion gate label_break_valueMazdak Farrokhzad-6/+1
2019-10-24dedup GAT gate checksMazdak Farrokhzad-16/+21
2019-10-24pre-expansion gate try_blocksMazdak Farrokhzad-3/+1
2019-10-24pre-expansion gate exclusive_range_patternMazdak Farrokhzad-6/+2
2019-10-24pre-expansion gate box_patternsMazdak Farrokhzad-14/+2
2019-10-24pre-expansion gate decl_macroMazdak Farrokhzad-5/+1
2019-10-24pre-expansion gate const_genericsMazdak Farrokhzad-11/+2
2019-10-24pre-expansion gate crate_visibility_modifierMazdak Farrokhzad-8/+1
2019-10-24pre-expansion gate associated_type_boundsMazdak Farrokhzad-14/+2
2019-10-24pre-expansion gate trait_alias.Mazdak Farrokhzad-9/+1
2019-10-23Auto merge of #57545 - bovinebuddha:object_safe_for_dispatch, r=nikomatsakisbors-0/+3
Object safe for dispatch cc #43561
2019-10-22RFC 2027: "first draft" of implementationMathias Blikstad-0/+3
These are a squashed series of commits.
2019-10-18Rollup merge of #65498 - SimonSapin:plugin-help, r=CentrilTyler Mandry-2/+8
Plugins deprecation: don’t suggest simply removing the attribute Building Servo with a recent Nightly produces: ```rust warning: use of deprecated attribute `plugin`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/issues/29597 --> components/script/lib.rs:14:1 | 14 | #![plugin(script_plugins)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this attribute | = note: `#[warn(deprecated)]` on by default ``` First, linking to https://github.com/rust-lang/rust/issues/29597 is not ideal since there is pretty much no discussion there of the deprecation and what can be used instead. This PR changes the link to the deprecation PR which does have more discussion. Second, the “remove this attribute” suggestion is rather unhelpful. Just because a feature is deprecated doesn’t mean that simply removing its use without a replacement is acceptable. In the case of custom lint, there is no replacement available. Prefixing a message with “help:” when telling users that they’re screwed honestly feels disrespectful. This PR also changes the message to be more factual.
2019-10-17Plugins deprecation: don’t suggest simply removing the attributeSimon Sapin-2/+8
Building Servo with a recent Nightly produces: ```rust warning: use of deprecated attribute `plugin`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/issues/29597 --> components/script/lib.rs:14:1 | 14 | #![plugin(script_plugins)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this attribute | = note: `#[warn(deprecated)]` on by default ``` First, linking to https://github.com/rust-lang/rust/issues/29597 is not ideal since there is pretty much no discussion there of the deprecation and what can be used instead. This PR changes the link to the deprecation PR which does have more discussion. Second, the “remove this attribute” suggestion is rather unhelpful. Just because a feature is deprecated doesn’t mean that simply removing its use without a replacement is acceptable. In the case of custom lint, there is no replacement available. Prefixing a message with “help:” when telling users that they’re screwed honestly feels disrespectful. This PR also changes the message to be more factual.
2019-10-16move syntax::ext to new crate syntax_expandMazdak Farrokhzad-3/+2
2019-10-15Rollup merge of #65426 - ↵Mazdak Farrokhzad-1/+1
nnethercote:rm-custom-LocalInternedString-PartialEq-impls, r=petrochenkov Remove custom `PartialEq` impls for `LocalInternedString`. This is on-trend with the recent changes simplifying `LocalInternedString` and reducing its use. r? @petrochenkov
2019-10-15syntax::parse::sess -> syntax::sessMazdak Farrokhzad-2/+3
2019-10-15move maybe_report_invalid_custom_discriminants to feature_gateMazdak Farrokhzad-3/+47
2019-10-15Remove custom `PartialEq` impls for `LocalInternedString`.Nicholas Nethercote-1/+1
This is on-trend with the recent changes simplifying `LocalInternedString` and reducing its use.
2019-10-13Rollup merge of #65214 - Amanieu:cfg_atomic, r=alexcrichtonMazdak Farrokhzad-0/+1
Split non-CAS atomic support off into target_has_atomic_load_store This PR implements my proposed changes in https://github.com/rust-lang/rust/issues/32976#issuecomment-518542029 by removing `target_has_atomic = "cas"` and splitting `target_has_atomic` into two separate `cfg`s: * `target_has_atomic = 8/16/32/64/128`: This indicates the largest width that the target can atomically CAS (which implies support for all atomic operations). * ` target_has_atomic_load_store = 8/16/32/64/128`: This indicates the largest width that the target can support loading or storing atomically (but may not support CAS). cc #32976 r? @alexcrichton
2019-10-13simplify maybe_stage_featuresMazdak Farrokhzad-14/+8
2019-10-08Split non-CAS atomic support off into target_has_atomic_load_storeAmanieu d'Antras-0/+1
2019-10-07Mark #![feature(track_caller)] as incomplete.Adam Perry-0/+1
2019-10-07track_caller feature gate starts in 1.40.0.Adam Perry-1/+1
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-10-07track_caller run-pass test, lint cleanup, PR review.Adam Perry-5/+2
2019-10-07[RFC 2091] Add #[track_caller] attribute.Ayose-0/+7
- The attribute is behind a feature gate. - Error if both #[naked] and #[track_caller] are applied to the same function. - Error if #[track_caller] is applied to a non-function item. - Error if ABI is not "rust" - Error if #[track_caller] is applied to a trait function. Error codes and descriptions are pending.
2019-10-07Fix compilation error after rebase.Charles Lew-1/+1
2019-10-07Address review comments.Charles Lew-4/+3
2019-10-07Add feature gate for raw_dylib.Charles Lew-1/+10
2019-10-07Auto merge of #64906 - Aaron1011:feature/extern-const-fn, r=Centrilbors-0/+4
Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: https://github.com/rust-lang/rust/issues/64926.
2019-10-03plugin_registrary: use normal deprecation instead of hard coded warning.Mazdak Farrokhzad-6/+10
2019-10-03Deprecate `#![plugin]` and `#[plugin_registrar]`.Mazdak Farrokhzad-3/+12
2019-10-02Add support for 'extern const fn'Aaron Hill-0/+4
This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.
2019-09-30Stabilize macros in `extern` blocksVadim Petrochenkov-3/+2
Add some tests for macros in extern blocks, remove duplicate tests
2019-09-28syntax: don't keep a redundant c_variadic flag in the AST.Eduard-Mihai Burtescu-3/+8
2019-09-26Rename `ForeignItem.node` to `ForeignItem.kind`varkor-1/+1
2019-09-26Rename `Item.node` to `Item.kind`varkor-1/+1
2019-09-26Rename `Ty.node` to `Ty.kind`varkor-2/+2
2019-09-26Rename `TraitItem.node` to `TraitItem.kind`varkor-1/+1
2019-09-26Rename `ImplItem.node` to `ImplItem.kind`varkor-1/+1
2019-09-26Rename `Pat.node` to `Pat.kind`varkor-2/+2
2019-09-26Rename `Expr.node` to `Expr.kind`varkor-1/+1
For both `ast::Expr` and `hir::Expr`.
2019-09-24add error message for caseAriel Ben-Yehuda-2/+1
2019-09-24reserve `impl<T> From<!> for T`Ariel Ben-Yehuda-0/+4
this is necessary for never-type stabilization
2019-09-21Rollup merge of #64010 - c410-f3r:stabilize-attrs-fn, r=CentrilMazdak Farrokhzad-4/+2
Stabilize `param_attrs` in Rust 1.39.0 # Stabilization proposal I propose that we stabilize `#![feature(param_attrs)]`. Tracking issue: #60406 Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable). ## What is stabilized It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example: ```rust fn len( #[cfg(windows)] slice: &[u16], #[cfg(not(windows))] slice: &[u8], ) -> usize { slice.len() } ``` ## What isn't stabilized * Documentation comments like `/// Doc` on parameters. * Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters. * Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters. ## Motivation The chief motivations for stabilizing `param_attrs` include: * Finer conditional compilation with `#[cfg(..)]` and linting control of variables. * Richer macro DSLs created by users. * External tools and compiler internals can take advantage of the additional information that the parameters provide. For more examples, see the [RFC][rfc motivation]. ## Reference guide In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from: ```rust FnParam = { pat:Pat ":" }? ty:Type; VaradicTail = "..."; ``` into: ```rust FnParam = OuterAttr* { pat:Pat ":" }? ty:Type; VaradicTail = OuterAttr* "..."; ``` The grammar of a closure parameter is changed from: ```rust ClosureParam = pat:Pat { ":" ty:Type }?; ``` into: ```rust ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?; ``` More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`. Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros. ## History * On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position". * On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made. * On 2019-06-12, a partial implementation was completed. The implementation was done in [#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril. * On 2019-07-29, [#61238][61238] was fixed in [#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk. * On 2019-08-02, a bug [#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed. * This PR stabilizes `param_attrs`. ## Tests * [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs) * [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs) * [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs) * [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) * [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns. * [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs) ## Possible future work * Custom attributes inside function parameters aren't currently supported but it is something being worked on internally. * Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters. [rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation [rfc]: https://github.com/rust-lang/rfcs/pull/2565 [60669]: https://github.com/rust-lang/rust/pull/60669 [61856]: https://github.com/rust-lang/rust/pull/61856 [63210]: https://github.com/rust-lang/rust/issues/63210 [61238]: https://github.com/rust-lang/rust/issues/61238 [63212]: https://github.com/rust-lang/rust/pull/63212 This report is a collaborative work with @Centril.
2019-09-14feature_gate: Eliminate `check::Context`Vadim Petrochenkov-59/+51
Use `PostExpansionVisitor` directly instead
2019-09-14feature_gate: Merge various attribute gating functionsVadim Petrochenkov-83/+43
2019-09-14feature_gate: Remove dead code from attribute checkingVadim Petrochenkov-42/+8
Same checks are performed during name resolution, and all attributes go through name resolution now
2019-09-11Stabilize `param_attrs` in Rust 1.39.0Caio-4/+2
2019-09-08Stabilize bind_by_move_pattern_guards in 1.39.0.Mazdak Farrokhzad-3/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 01:14:21 +0000