| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Point to the current box syntax tracking issue
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
r? @aidanhs
|
|
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
|
|
restore emplacement syntax (obsolete)
Fix https://github.com/rust-lang/rust/issues/50832
r? @petrochenkov
|
|
Add tests, documentation and attr for feature.
|
|
|
|
|
|
|
|
rustc: Disallow modules and macros in expansions
This commit feature gates generating modules and macro definitions in procedural
macro expansions. Custom derive is exempt from this check as it would be a large
retroactive breaking change (#50587). It's hoped that we can hopefully stem the
bleeding to figure out a better solution here before opening up the floodgates.
The restriction here is specifically targeted at surprising hygiene results [1]
that result in non-"copy/paste" behavior. Hygiene and procedural macros is
intended to be avoided as much as possible for Macros 1.2 by saying everything
is "as if you copy/pasted the code", but modules and macros are sort of weird
exceptions to this rule that aren't fully fleshed out.
[1]: https://github.com/rust-lang/rust/issues/50504#issuecomment-387734625
cc #50504
|
|
This commit feature gates generating modules and macro definitions in procedural
macro expansions. Custom derive is exempt from this check as it would be a large
retroactive breaking change (#50587). It's hoped that we can hopefully stem the
bleeding to figure out a better solution here before opening up the floodgates.
The restriction here is specifically targeted at surprising hygiene results [1]
that result in non-"copy/paste" behavior. Hygiene and procedural macros is
intended to be avoided as much as possible for Macros 1.2 by saying everything
is "as if you copy/pasted the code", but modules and macros are sort of weird
exceptions to this rule that aren't fully fleshed out.
[1]: https://github.com/rust-lang/rust/issues/50504#issuecomment-387734625
cc #50504
|
|
|
|
|
|
|
|
|
|
Implements RFC 1576.
See: https://github.com/rust-lang/rfcs/blob/master/text/1576-macros-literal-matcher.md
Changes are mostly in libsyntax, docs, and tests. Feature gate is
enabled for 1.27.0.
Many thanks to Vadim Petrochenkov for following through code reviews
and suggestions.
Example:
````rust
macro_rules! test_literal {
($l:literal) => {
println!("literal: {}", $l);
};
($e:expr) => {
println!("expr: {}", $e);
};
}
fn main() {
let a = 1;
test_literal!(a);
test_literal!(2);
test_literal!(-3);
}
```
Output:
```
expr: 1
literal: 2
literal: -3
```
|
|
This commit fixes a hard error where the `#![feature(rust_2018_preview)]`
feature was forbidden to be mentioned when the `--edition 2018` flag was passed.
This instead silently accepts that feature gate despite it not being necessary.
It's intended that this will help ease the transition into the 2018 edition as
users will, for the time being, start off with the `rust_2018_preview` feature
and no longer immediately need to remove it.
Closes #50662
|
|
NLL isn't quite ready yet so gonna hold off on inserting it into the preview.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove unstable `macro_reexport`
It's subsumed by `feature(use_extern_macros)` and `pub use`
cc https://github.com/rust-lang/rust/issues/35896
closes https://github.com/rust-lang/rust/issues/29638
closes https://github.com/rust-lang/rust/issues/38951
|
|
Module experiments: Add one more prelude layer for extern crate names passed with `--extern`
Implements one item from https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/183
When some name is looked up in lexical scope (`name`, i.e. not module-relative scope `some_mod::name` or `::name`), it's searched roughly in the next order:
- local variables
- items in unnamed blocks
- items in the current module
- :sparkles: NEW! :sparkles: crate names passed with `--extern` ("extern prelude")
- standard library prelude (`Vec`, `drop`)
- language prelude (built-in types like `u8`, `str`, etc)
The last two layers contain a limited set of names controlled by us and not arbitrary user-defined names like upper layers. We want to be able to add new names into these two layers without breaking user code, so "extern prelude" names have higher priority than std prelude and built-in types.
This is a one-time breaking change, that's why it would be nice to run this through crater.
Practical impact is expected to be minimal though due to stylistic reasons (there are not many `Uppercase` crates) and due to the way how primitive types are resolved (https://github.com/rust-lang/rust/pull/32131).
|
|
|
|
It's subsumed by `feature(use_extern_macros)` and `pub use`
|
|
This is in the matter of RFC 1940 and tracking issue #43302.
|
|
Stabilize dyn trait
This PR stabilizes RFC 2113. I followed the [stabilization guide](https://forge.rust-lang.org/stabilization-guide.html).
Related issue: https://github.com/rust-lang/rust/issues/49218
|
|
|
|
|
|
|
|
|
|
Tweak some warnings around #[target_feature]
This commit fixes up some issues discovered when getting the `stdsimd` crate's CI compiling again.
|
|
don't see issue #0
The unstable-feature attribute requires an issue (neglecting it is
E0547), which gets used in the error messages. Unfortunately, there are
some cases where "0" is apparently used a placeholder where no issue
exists, directing the user to see the (nonexistent) issue #0. (It would
have been better to either let `issue` be optional—compare to how issue
is an `Option<u32>` in the feature-gate declarations in
libsyntax/feature-gate.rs—or actually require that an issue be created.)
Rather than endeavoring to change how `#[unstable]` works at this time
(given competing contributor and reviewer priorities), this simple patch
proposes the less-ambitious solution of just not adding the "(see
issue)" note when the number is zero.
Resolves #49983.
|
|
Feature gate where clauses on associated types
Fixes #49365. Requires crater: these have been usable since 1.24.
|
|
Add specific never search
Fixes #49529.
r? @QuietMisdreavus
|
|
|
|
r=alexcrichton
Revert stabilization of never_type (!) et al
Fix #49691
I *think* this correctly adopts @nikomatsakis 's desired fix of:
* reverting stabilization of `!` and `TryFrom`, and
* returning to the previous fallback semantics (i.e. it is once again dependent on whether the crate has opted into `#[feature(never_type)]`,
* **without** attempting to put back in the previous future-proofing warnings regarding the change in fallback semantics.
(I'll be away from computers for a week starting now, so any updates to this PR should be either pushed into it, or someone else should adopt the task of polishing this fix and put up their own PR.)
|
|
|
|
This commit starts to lay some groundwork for the stabilization of custom
attribute invocations and general procedural macros. It applies a number of
changes discussed on [internals] as well as a [recent issue][issue], namely:
* The path used to specify a custom attribute must be of length one and cannot
be a global path. This'll help future-proof us against any ambiguities and
give us more time to settle the precise syntax. In the meantime though a bare
identifier can be used and imported to invoke a custom attribute macro. A new
feature gate, `proc_macro_path_invoc`, was added to gate multi-segment paths
and absolute paths.
* The set of items which can be annotated by a custom procedural attribute has
been restricted. Statements, expressions, and modules are disallowed behind
two new feature gates: `proc_macro_expr` and `proc_macro_mod`.
* The input to procedural macro attributes has been restricted and adjusted.
Today an invocation like `#[foo(bar)]` will receive `(bar)` as the input token
stream, but after this PR it will only receive `bar` (the delimiters were
removed). Invocations like `#[foo]` are still allowed and will be invoked in
the same way as `#[foo()]`. This is a **breaking change** for all nightly
users as the syntax coming in to procedural macros will be tweaked slightly.
* Procedural macros (`foo!()` style) can only be expanded to item-like items by
default. A separate feature gate, `proc_macro_non_items`, is required to
expand to items like expressions, statements, etc.
Closes #50038
[internals]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
[issue]: https://github.com/rust-lang/rust/issues/50038
|
|
This commit is just covering the feature gate itself and the tests
that made direct use of `!` and thus need to opt back into the
feature.
A follow on commit brings back the other change that motivates the
revert: Namely, going back to the old rules for falling back to `()`.
|
|
This commit transitions the `target_feature` attribute from `Normal` to
`Whitelisted`. Discovered in #50095 the fact of whether this attribute is used
or not is dependent on typechecking running and executing `check_name`, but
incremental compilation doesn't currently account for this, meaning that the
attribute ends up being flagged as unused when it shouldn't be.
I was a little too ambitious it seems hoping that `Normal` could be used, so
instead this transitions to `Whitelisted` to be the same as other codegen
attributes like `#[inline]`
Closes #50095
|
|
Stabilize x86/x86_64 SIMD
This commit stabilizes the SIMD in Rust for the x86/x86_64 platforms. Notably
this commit is stabilizing:
* The `std::arch::{x86, x86_64}` modules and the intrinsics contained inside.
* The `is_x86_feature_detected!` macro in the standard library
* The `#[target_feature(enable = "...")]` attribute
* The `#[cfg(target_feature = "...")]` matcher
Stabilization of the module and intrinsics were primarily done in
rust-lang-nursery/stdsimd#414 and the two attribute stabilizations are done in
this commit. The standard library is also tweaked a bit with the new way that
stdsimd is integrated.
Note that other architectures like `std::arch::arm` are not stabilized as part
of this commit, they will likely stabilize in the future after they've been
implemented and fleshed out. Similarly the `std::simd` module is also not being
stabilized in this commit, only `std::arch`. Finally, nothing related to `__m64`
is stabilized in this commit either (MMX), only SSE and up types and intrinsics
are stabilized.
Closes #29717
Closes #44839
Closes #48556
|
|
Use an explicit whitelist for what features are actually stable and can be
enabled.
|
|
feature list
These are already stabilized in 1.26.
|
|
This commit stabilizes the SIMD in Rust for the x86/x86_64 platforms. Notably
this commit is stabilizing:
* The `std::arch::{x86, x86_64}` modules and the intrinsics contained inside.
* The `is_x86_feature_detected!` macro in the standard library
* The `#[target_feature(enable = "...")]` attribute
* The `#[cfg(target_feature = "...")]` matcher
Stabilization of the module and intrinsics were primarily done in
rust-lang-nursery/stdsimd#414 and the two attribute stabilizations are done in
this commit. The standard library is also tweaked a bit with the new way that
stdsimd is integrated.
Note that other architectures like `std::arch::arm` are not stabilized as part
of this commit, they will likely stabilize in the future after they've been
implemented and fleshed out. Similarly the `std::simd` module is also not being
stabilized in this commit, only `std::arch`. Finally, nothing related to `__m64`
is stabilized in this commit either (MMX), only SSE and up types and intrinsics
are stabilized.
Closes #29717
Closes #44839
Closes #48556
|
|
The unstable-feature attribute requires an issue (neglecting it is
E0547), which gets used in the error messages. Unfortunately, there are
some cases where "0" is apparently used a placeholder where no issue
exists, directing the user to see the (nonexistent) issue #0. (It would
have been better to either let `issue` be optional—compare to how issue
is an `Option<u32>` in the feature-gate declarations in
libsyntax/feature-gate.rs—or actually require that an issue be created.)
Rather than endeavoring to change how `#[unstable]` works at this time
(given competing contributor and reviewer priorities), this simple patch
proposes the less-ambitious solution of just not adding the "(see
issue)" note when the number is zero.
Resolves #49983.
|
