about summary refs log tree commit diff
path: root/src/libsyntax/feature_gate
AgeCommit message (Collapse)AuthorLines
2019-10-27Stabilize `const_constructor`Matthew Jasper-3/+2
2019-10-25Add proper tracking issue for EFIAPIroblabla-1/+1
2019-10-25Add new EFIAPI ABIroblabla-0/+7
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest version of the UEFI specification at the time of commit (UEFI spec 2.8, URL below). The specification says that for x86_64, we should follow the win64 ABI, while on all other supported platforms (ia32, itanium, arm, arm64 and risc-v), we should follow the C ABI. To simplify the implementation, we will simply follow the C ABI on all platforms except x86_64, even those technically unsupported by the UEFI specification. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
2019-10-25RFC 2008: StabilizationDavid Wood-7/+4
This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood <david@davidtw.co>
2019-10-25Rollup merge of #65747 - Centril:union-issue-fix, r=varkorMazdak Farrokhzad-5/+13
Adjust the tracking issue for `untagged_unions`. Makes https://github.com/rust-lang/rust/issues/55149 the new tracking issue for `untagged_unions`. Closes https://github.com/rust-lang/rust/issues/32836 which is the old tracking issue. r? @varkor
2019-10-24Adjust the tracking issue for `untagged_unions`.Mazdak Farrokhzad-5/+13
Also elaborate on some feature gates in `active.rs`.
2019-10-24pre-expansion gate type_ascriptionMazdak Farrokhzad-15/+6
2019-10-24pre-expansion gate box_syntaxMazdak Farrokhzad-6/+1
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`.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-28 03:36:36 +0000