| Age | Commit message (Collapse) | Author | Lines |
|
Issue: 54912
|
|
Fixes #47311.
r? @nrc
|
|
Fixes #47311.
r? @nrc
|
|
|
|
|
|
oli-obk:mögen_konstante_funktionen_doch_bitte_endlich_stabil_sein, r=Centril
Stabilize `min_const_fn`
tracking issue: #53555
r? @Centril
|
|
|
|
resolve: Some refactorings in preparation for uniform paths 2.0
The main result is that in-scope resolution performed during macro expansion / import resolution is now consolidated in a single function (`fn early_resolve_ident_in_lexical_scope`), which can now be used for resolving first import segments as well when uniform paths are enabled.
r? @ghost
|
|
|
|
|
|
The restrictions were introduced in https://github.com/rust-lang/rust/pull/54277 and no longer necessary now because legacy plugins are now expanded in usual left-to-right order
|
|
`proc_macro_hygiene` gate.
|
|
|
|
Stabilize pattern_parentheses feature
Addresses #51087 .
Stabilizes the previously unstable feature `pattern_parentheses` which enables the use of `()` in match patterns.
|
|
`impl trait` in bindings (feature: impl-trait-existential-types)
This PR enables `impl Trait` syntax (opaque types) to be used in bindings, e.g.
* `let foo: impl Clone = 1;`
* `static foo: impl Clone = 2;`
* `const foo: impl Clone = 3;`
This is part of [RFC 2071](https://github.com/rust-lang/rfcs/blob/master/text/2071-impl-trait-existential-types.md) ([tracking issue](https://github.com/rust-lang/rust/issues/34511)), but exists behind the separate feature gate `impl_trait_in_bindings`.
CC @cramertj @oli-obk @eddyb @Centril @varkor
|
|
Support an explicit annotation for marker traits
From the tracking issue for rust-lang/rfcs#1268:
> It seems obvious that we should make a `#[marker]` annotation. ~ https://github.com/rust-lang/rust/issues/29864#issuecomment-368959441
This PR allows you to put `#[marker]` on a trait, at which point:
- [x] The trait must not have any items ~~All of the trait's items must have defaults~~
- [x] Any impl of the trait must be empty (not override any items)
- [x] But impls of the trait are allowed to overlap
r? @nikomatsakis
|
|
|
|
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO.
This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way.
I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo.
r? @alexcrichton
|
|
|
|
editions.
|
|
|
|
test incremental ThinLTO.
|
|
r=nikomatsakis
Add feature to enable bind by move pattern guards
Implement #15287 as described on https://github.com/rust-lang/rust/issues/15287#issuecomment-404827419
|
|
Issue 54246
I added the option of providing a help message for deprecated features, that takes precedence over the default `help: remove this attribute` message, along with messages for the features that mention replacements in the reason for deprecation.
Fixes #54246.
|
|
|
|
|
|
Note it requires MIR-borrowck to be enabled to actually do anything.
Note also that it implicitly turns off our AST-based check for
mutation in guards.
|
|
... and also proc macro attributes used together with test/bench.
|
|
|
|
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Stabilization change for mod.rs
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
|
|
Co-authored-by: nikomatsakis
|
|
stabilize #[used]
closes #40289
RFC for stabilization: rust-lang/rfcs#2386
r? @Centril
Where should this be documented? Currently the documentation is in the unstable book
|
|
|
|
|
|
resolve: Relax shadowing restrictions on macro-expanded macros
Previously any macro-expanded macros weren't allowed to shadow macros from outer scopes.
Now only "more macro-expanded" macros cannot shadow "less macro-expanded" macros.
See comments to `fn may_appear_after` and added tests for more details and examples.
The functional changes are a21f6f588fc28c97533130ae44a6957b579ab58c and 46dd365ce9ca0a6b8653849b80267763c542842a, other commits are refactorings.
|
|
closes #40289
|
|
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
|
|
|
|
Whitelist `#[rustc_transparent_macro]` so it's not interpreted as a potential attribute macro
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #53076 (set cfg(rustdoc) when rustdoc is running on a crate)
- #53622 (cleanup: Add main functions to some UI tests)
- #53769 (Also link Clippy repo in the CONTRIBUTING.md file)
- #53774 (Add rust-gdbgui script.)
- #53781 (bench: libcore: fix build failure of any.rs benchmark (use "dyn Any"))
- #53782 (Make Arc cloning mechanics clearer in module docs)
- #53790 (Add regression test for issue #52060)
- #53801 (Prevent duplicated impl on foreign types)
- #53850 (Nuke the `const_to_allocation` query)
|
|
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
|
|
|
|
|
|
r=cramertj
Fix stabilisation version for macro_vis_matcher.
r? @cramertj
|