| 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`
|
|
stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940)
r? @nikomatsakis
|
|
Use enum for approximate suggestions
r? @nrc @killercup
|
|
Warn on pointless #[derive] in more places
This fixes the regression in #49934 and ensures that unused `#[derive]` invocations on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. There is a separate warning hardcoded for `#[derive]` on macro invocations since linting (even the early-lint pass) occurs after expansion. This also adds regression tests for some nodes that were already warning properly.
closes #49934
|
|
This fixes the regression in #49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.
closes #49934
|
|
Improve error message for #[repr(align=x)]
Before:
```
error[E0552]: unrecognized representation hint
--> src/main.rs:1:8
|
1 | #[repr(align="8")]
| ^^^^^^^^^
```
After:
```
error[E0693]: incorrect `repr(align)` attribute format
--> src/main.rs:1:8
|
2 | #[repr(align="8")]
| ^^^^^^^^^ help: use parentheses instead: `align(8)`
```
Fixes #50314.
|
|
|
|
This is in the matter of RFC 1940 and tracking issue #43302.
|
|
'label can start expressions
```Rust
let foo = 'label: loop { break 'label 42; };
```
is valid Rust code.
|
|
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 allow #[should_panic] with non-() tests
Adds (removes) support for `#[should_panic]` when the test is non-`()`
|
|
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.
|
|
|
|
let foo = 'label: loop { break 'label 42; };
is valid Rust code.
|
|
Doc comments present after a particular syntax error cause an unhelpful error message to be output.
fixed: #48636
r? @estebank
|
|
parser: Do not override syntactic context for dummy spans
Fixes https://github.com/rust-lang/rust/issues/50061
https://github.com/rust-lang/rust/commit/e2afefd80bf779bc3c6f697a3c6cc3a476993602 seemingly did everything right, but uncovered a preexisting bug.
|
|
2) Changed position of help message, incase comma is missing
3) added few missing spaces and handled span_suggestion for vscode
4) updated stderr file
|
|
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.)
|
|
|
|
rustc: Tweak custom attribute capabilities
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
|
|
add --edition option
This adds an official `edition` flag to the rust compiler
|
|
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 `()`.
|
|
Avoid allocating when parsing \u{...} literals.
`char_lit` uses an allocation in order to ignore '_' chars in \u{...}
literals. This patch changes it to not do that by processing the chars
more directly.
This improves various rustc-perf benchmark measurements by up to 6%,
particularly regex, futures, clap, coercions, hyper, and encoding.
rustc-perf results, on a stage 2 build with jemalloc disabled:
<details>
```
regex-check
avg: -5.4% min: -6.5% max: -2.7%
futures-check
avg: -3.5% min: -5.3% max: -1.7%
regex-opt
avg: -2.0% min: -5.1% max: -0.2%
regex
avg: -2.3% min: -5.0% max: -0.6%
futures-opt
avg: -3.0% min: -4.8% max: -1.1%
futures
avg: -3.1% min: -4.8% max: -1.3%
clap-rs-check
avg: -1.8% min: -3.5% max: -0.9%
coercions-check
avg: -2.0% min: -3.3% max: -1.0%
hyper-check
avg: -2.2% min: -3.1% max: -1.3%
hyper
avg: -1.3% min: -2.4% max: -0.3%
hyper-opt
avg: -0.9% min: -2.3% max: -0.1%
coercions
avg: -1.1% min: -2.2% max: -0.4%
encoding-check
avg: -1.7% min: -2.2% max: -0.9%
clap-rs-opt
avg: -0.7% min: -2.2% max: 0.0%
coercions-opt
avg: -1.2% min: -2.1% max: -0.3%
clap-rs
avg: -0.8% min: -1.9% max: -0.4%
encoding-opt
avg: -1.0% min: -1.9% max: -0.3%
encoding
avg: -1.1% min: -1.9% max: -0.4%
piston-image-check
avg: -0.7% min: -1.3% max: -0.3%
inflate-opt
avg: -0.3% min: -0.9% max: -0.0%
piston-image
avg: -0.3% min: -0.8% max: -0.1%
piston-image-opt
avg: -0.3% min: -0.7% max: -0.1%
syn-check
avg: -0.3% min: -0.6% max: -0.1%
deep-vector
avg: 0.1% min: -0.1% max: 0.5%
syn-opt
avg: -0.1% min: -0.4% max: 0.0%
html5ever
avg: -0.2% min: -0.4% max: -0.0%
deep-vector-check
avg: 0.0% min: -0.3% max: 0.3%
syn
avg: -0.2% min: -0.3% max: -0.1%
html5ever-check
avg: -0.3% min: -0.3% max: -0.2%
issue-46449-check
avg: -0.1% min: -0.2% max: 0.2%
html5ever-opt
avg: -0.0% min: -0.2% max: 0.1%
deep-vector-opt
avg: -0.0% min: -0.2% max: 0.1%
issue-46449-opt
avg: -0.0% min: -0.2% max: 0.1%
unify-linearly-check
avg: -0.0% min: -0.2% max: 0.1%
helloworld-check
avg: 0.0% min: -0.0% max: 0.2%
parser-check
avg: -0.0% min: -0.2% max: 0.0%
inflate
avg: 0.0% min: -0.0% max: 0.1%
tokio-webpush-simple-check
avg: -0.1% min: -0.1% max: -0.0%
regression-31157-check
avg: 0.0% min: -0.1% max: 0.1%
issue-46449
avg: 0.0% min: -0.1% max: 0.1%
tuple-stress-opt
avg: 0.0% min: -0.0% max: 0.1%
tuple-stress-check
avg: -0.0% min: -0.1% max: 0.1%
tuple-stress
avg: 0.0% min: -0.0% max: 0.1%
deeply-nested-check
avg: 0.0% min: -0.0% max: 0.1%
regression-31157
avg: -0.0% min: -0.1% max: 0.1%
deeply-nested-opt
avg: -0.0% min: -0.1% max: 0.1%
parser-opt
avg: -0.0% min: -0.1% max: 0.0%
parser
avg: 0.1% min: 0.0% max: 0.1%
tokio-webpush-simple
avg: -0.0% min: -0.1% max: 0.1%
regression-31157-opt
avg: -0.0% min: -0.1% max: 0.1%
helloworld-opt
avg: 0.0% min: -0.0% max: 0.1%
unify-linearly-opt
avg: 0.0% min: -0.0% max: 0.1%
unused-warnings-check
avg: 0.0% min: 0.0% max: 0.1%
tokio-webpush-simple-opt
avg: -0.0% min: -0.1% max: 0.0%
helloworld
avg: -0.0% min: -0.0% max: 0.1%
unused-warnings
avg: 0.0% min: -0.0% max: 0.0%
deeply-nested
avg: -0.0% min: -0.0% max: -0.0%
unused-warnings-opt
avg: 0.0% min: -0.0% max: 0.0%
unify-linearly
avg: 0.0% min: -0.0% max: 0.0%
inflate-check
avg: 0.0% min: -0.0% max: 0.0%
```
</details>
|
|
editions are allowed to be used on non-nightly builds
|
|
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
|
|
|
|
Discovered in #50061 we're falling off the "happy path" of using a stringified
token stream more often than we should. This was due to the fact that a
user-written token like `0xf` is equality-different from the stringified token
of `15` (despite being semantically equivalent).
This patch updates the call to `eq_unspanned` with an even more awful solution,
`probably_equal_for_proc_macro`, which ignores the value of each token and
basically only compares the structure of the token stream, assuming that the AST
doesn't change just one token at a time.
While this is a step towards fixing #50061 there is still one regression
from #49154 which needs to be fixed.
|
|
`char_lit` uses an allocation in order to ignore '_' chars in \u{...}
literals. This patch changes it to not do that by processing the chars
more directly.
This improves various rustc-perf benchmark measurements by up to 6%,
particularly regex, futures, clap, coercions, hyper, and encoding.
|
|
Reorder injection of std to get better compilation error
Per #49851, reorder injection imports to get a better error message.
r? @oli-obk
|
|
Change the hashcounts in raw `Lit` variants from usize to u16.
This reduces the size of `Token` from 32 bytes to 24 bytes on 64-bit
platforms.
|
|
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.
|
