| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
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.
|
|
union, and projection types. added a feature gate and tests for these scenarios.
|
|
|
|
Correct a few stability attributes
* `const_indexing` language feature was stabilized in 1.26.0 by #46882
* `Display` impls for `PanicInfo` and `Location` were stabilized in 1.26.0 by #47687
* `TrustedLen` is still unstable so its impls should be as well even though `RangeInclusive` was stabilized by #47813
* `!Send` and `!Sync` for `Args` and `ArgsOs` were stabilized in 1.26.0 by #48005
* `EscapeDefault` has been stable since 1.0.0 so should continue to show that even though it was moved to core in #48735
This could be backported to beta like #49612
|
|
|
|
|
|
|
|
|
|
Expand macros in `extern {}` blocks
This permits macro and proc-macro and attribute invocations (the latter only with the `proc_macro` feature of course) in `extern {}` blocks, gated behind a new `macros_in_extern` feature.
A tracking issue is now open at #49476
closes #48747
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #48658 (Add a generic CAS loop to std::sync::Atomic*)
- #49253 (Take the original extra-filename passed to a crate into account when resolving it as a dependency)
- #49345 (RFC 2008: Finishing Touches)
- #49432 (Flush executables to disk after linkage)
- #49496 (Add more vec![... ; n] optimizations)
- #49563 (add a dist builder to build rust-std components for the THUMB targets)
- #49654 (Host compiler documentation: Include private items)
- #49667 (Add more features to rust_2018_preview)
- #49674 (ci: Remove x86_64-gnu-incremental builder)
Failed merges:
|
|
|
|
|
|
|
|
Closes #22181, #27779
|
|
Easy edition feature flag
We no longer gate features on epochs; instead we have a `#![feature(rust_2018_preview)]` that flips on a bunch of features (currently dyn_trait).
Based on #49001 to avoid merge conflicts
r? @nikomatsakis
|
|
Retains the `stmt_expr_attributes` feature requirement for attributes on expressions.
closes #41475
cc #38356
|
|
|
|
|
|
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
|
|
|
|
|
