about summary refs log tree commit diff
path: root/compiler/rustc_feature/src
AgeCommit message (Collapse)AuthorLines
2024-06-24coverage: Forbid multiple `#[coverage(..)]` attributesZalathar-1/+1
It might make sense to allow this in the future, if we add values that aren't mutually exclusive, but for now having multiple coverage attributes on one item is useless.
2024-06-24Rollup merge of #126177 - carbotaniuman:unsafe_attr_errors, r=jieyouxuMatthias Krüger-5/+1
Add hard error and migration lint for unsafe attrs More implementation work for https://github.com/rust-lang/rust/issues/123757 This adds the migration lint for unsafe attributes, as well as making it a hard error in Rust 2024.
2024-06-23Add hard error and migration lint for unsafe attrscarbotaniuman-5/+1
2024-06-23Rollup merge of #126830 - RalfJung:unsized-fn-params, r=compiler-errorsMatthias Krüger-1/+1
make unsized_fn_params an internal feature As suggested [here](https://github.com/rust-lang/rust/pull/123894#issuecomment-2054043053). r? `@compiler-errors` Fixes https://github.com/rust-lang/rust/issues/123887 (kind of -- ICEs on internal features are considered acceptable so this issue is not-a-bug once this PR lands)
2024-06-24SmartPointer derive-macroXiangfei Ding-0/+8
Co-authored-by: Wedson Almeida Filho <walmeida@microsoft.com>
2024-06-22Rollup merge of #126552 - fee1-dead-contrib:rmfx, r=compiler-errorsMatthias Krüger-1/+1
Remove use of const traits (and `feature(effects)`) from stdlib The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands. Also, make `effects` an incomplete feature. cc `@rust-lang/project-const-traits` r? `@compiler-errors`
2024-06-22Make `effects` an incomplete featureDeadbeef-1/+1
2024-06-22make unsized_fn_params an internal featureRalf Jung-1/+1
2024-06-22Add `#[rustc_dump_{predicates,item_bounds}]`León Orell Valerian Liehr-0/+8
2024-06-20Auto merge of #116088 - nbdd0121:unwind, r=Amanieu,RalfJungbors-2/+2
Stabilise `c_unwind` Fix #74990 Fix #115285 (that's also where FCP is happening) Marking as draft PR for now due to `compiler_builtins` issues r? `@Amanieu`
2024-06-19Rollup merge of #126668 - fmease:rm-rustc_dump_program_clauses-attrs, ↵fee1-dead-8/+0
r=fee1-dead Remove now NOP attrs `#[rustc_dump{,_env}_program_clauses]` Likely NOP since #113303. r? `@fee1-dead`
2024-06-19Stabilise c_unwindGary Guo-2/+2
2024-06-19Remove now NOP attrs `#[rustc_dump{,_env}_program_clauses]`León Orell Valerian Liehr-8/+0
2024-06-19Rollup merge of #125293 - dingxiangfei2009:tail-expr-temp-lifetime, ↵许杰友 Jieyou Xu (Joe)-0/+2
r=estebank,davidtwco Place tail expression behind terminating scope This PR implements #123739 so that we can do further experiments in nightly. A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following. ```rust match into_async_iter($iter_expr) { ref mut iter => match unsafe { Pin::unchecked_new(iter) } { ... } } ```
2024-06-17Delay a bug and mark precise_capturing as not incompleteMichael Goulet-1/+1
2024-06-17Rework precise capturing syntaxMichael Goulet-1/+1
2024-06-18tail expression behind terminating scopeDing Xiang Fei-0/+2
2024-06-14Auto merge of #118958 - c410-f3r:concat-again, r=petrochenkovbors-0/+2
Add a new concat metavar expr Revival of #111930 Giving it another try now that #117050 was merged. With the new rules, meta-variable expressions must be referenced with a dollar sign (`$`) and this can cause misunderstands with `$concat`. ```rust macro_rules! foo { ( $bar:ident ) => { const ${concat(VAR, bar)}: i32 = 1; }; } // Will produce `VARbar` instead of `VAR_123` foo!(_123); ``` In other words, forgetting the dollar symbol can produce undesired outputs. cc #29599 cc https://github.com/rust-lang/rust/issues/124225
2024-06-13Add a new concat metavar exprCaio-0/+2
2024-06-12Auto merge of #126273 - pietroalbini:pa-bootstrap-update, r=Mark-Simulacrumbors-7/+7
Bump stage0 to 1.80.0 r? `@Mark-Simulacrum`
2024-06-12Use `tidy` to sort crate attributes for all compiler crates.Nicholas Nethercote-1/+3
We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`. For the ones we don't, in many cases the attributes are a mess. - There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`). - Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order. - Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`. This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions. Exceptions: - `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes. - `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`).
2024-06-11replace version placeholderPietro Albini-7/+7
2024-06-08offset_of: allow (unstably) taking the offset of slice tail fieldsRalf Jung-0/+2
2024-06-06Fix orderingcarbotaniuman-2/+2
2024-06-06Remove extraneous attributecarbotaniuman-1/+0
2024-06-06Add unsafe to `ffi_pure` and `ffi_const`carbotaniuman-2/+2
2024-06-06Fix doc commentcarbotaniuman-1/+2
2024-06-06Error on unsafe on non-unsafe attributecarbotaniuman-2/+6
2024-06-06Reorder `unsafe` macro casescarbotaniuman-12/+12
2024-06-06Parse unsafe attributescarbotaniuman-3/+54
2024-06-06Auto merge of #124482 - spastorino:unsafe-extern-blocks, r=oli-obkbors-0/+2
Unsafe extern blocks This implements RFC 3484. Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484 This is better reviewed commit by commit.
2024-06-06Rollup merge of #125168 - ↵Matthias Krüger-4/+3
Jules-Bertholet:match-ergonomics-2024-align-with-rfc, r=Nadrieril Match ergonomics 2024: align implementation with RFC - Remove eat-two-layers (`ref_pat_everywhere`) - Consolidate `mut_preserve_binding_mode_2024` into `ref_pat_eat_one_layer_2024` - `&mut` no longer peels off `&` - Apply "no `ref mut` behind `&`" rule on all editions with `ref_pat_eat_one_layer_2024` - Require `mut_ref` feature gate for all mutable by-reference bindings r? ``@Nadrieril`` cc https://github.com/rust-lang/rust/issues/123076 ``@rustbot`` label A-edition-2024 A-patterns
2024-06-05Add unsafe_extern_blocks feature flagSantiago Pastorino-0/+2
2024-06-04Rollup merge of #124486 - beetrees:vectorcall-tracking-issue, r=ehuss许杰友 Jieyou Xu (Joe)-2/+2
Add tracking issue and unstable book page for `"vectorcall"` ABI Originally added in 2015 by #30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now. Tracking issue: #124485
2024-06-01Auto merge of #124577 - ↵bors-2/+2
GuillaumeGomez:stabilize-custom_code_classes_in_docs, r=rustdoc Stabilize `custom_code_classes_in_docs` feature Fixes #79483. This feature has been around for quite some time now, I think it's fine to stabilize it now. ## Summary ## What is the feature about? In short, this PR changes two things, both related to codeblocks in doc comments in Rust documentation: * Allow to disable generation of `language-*` CSS classes with the `custom` attribute. * Add your own CSS classes to a code block so that you can use other tools to highlight them. #### The `custom` attribute Let's start with the new `custom` attribute: it will disable the generation of the `language-*` CSS class on the generated HTML code block. For example: ```rust /// ```custom,c /// int main(void) { /// return 0; /// } /// ``` ``` The generated HTML code block will not have `class="language-c"` because the `custom` attribute has been set. The `custom` attribute becomes especially useful with the other thing added by this feature: adding your own CSS classes. #### Adding your own CSS classes The second part of this feature is to allow users to add CSS classes themselves so that they can then add a JS library which will do it (like `highlight.js` or `prism.js`), allowing to support highlighting for other languages than Rust without increasing burden on rustdoc. To disable the automatic `language-*` CSS class generation, you need to use the `custom` attribute as well. This allow users to write the following: ```rust /// Some code block with `{class=language-c}` as the language string. /// /// ```custom,{class=language-c} /// int main(void) { /// return 0; /// } /// ``` fn main() {} ``` This will notably produce the following HTML: ```html <pre class="language-c"> int main(void) { return 0; }</pre> ``` Instead of: ```html <pre class="rust rust-example-rendered"> <span class="ident">int</span> <span class="ident">main</span>(<span class="ident">void</span>) { <span class="kw">return</span> <span class="number">0</span>; } </pre> ``` To be noted, we could have written `{.language-c}` to achieve the same result. `.` and `class=` have the same effect. One last syntax point: content between parens (`(like this)`) is now considered as comment and is not taken into account at all. In addition to this, I added an `unknown` field into `LangString` (the parsed code block "attribute") because of cases like this: ```rust /// ```custom,class:language-c /// main; /// ``` pub fn foo() {} ``` Without this `unknown` field, it would generate in the DOM: `<pre class="language-class:language-c language-c">`, which is quite bad. So instead, it now stores all unknown tags into the `unknown` field and use the first one as "language". So in this case, since there is no unknown tag, it'll simply generate `<pre class="language-c">`. I added tests to cover this. EDIT(camelid): This description is out-of-date. Using `custom,class:language-c` will generate the output `<pre class="language-class:language-c">` as would be expected; it treats `class:language-c` as just the name of a language (similar to the langstring `c` or `js` or what have you) since it does not use the designed class syntax. Finally, I added a parser for the codeblock attributes to make it much easier to maintain. It'll be pretty easy to extend. As to why this syntax for adding attributes was picked: it's [Pandoc's syntax](https://pandoc.org/MANUAL.html#extension-fenced_code_attributes). Even if it seems clunkier in some cases, it's extensible, and most third-party Markdown renderers are smart enough to ignore Pandoc's brace-delimited attributes (from [this comment](https://github.com/rust-lang/rust/pull/110800#issuecomment-1522044456)). r? `@notriddle`
2024-05-29Make `std::env::{set_var, remove_var}` unsafe in edition 2024Tobias Bucher-0/+6
Allow calling these functions without `unsafe` blocks in editions up until 2021, but don't trigger the `unused_unsafe` lint for `unsafe` blocks containing these functions. Fixes #27970. Fixes #90308. CC #124866.
2024-05-15Gate implicit mutable by-reference bindings behind `mut ref`Jules Bertholet-2/+2
2024-05-15Remove `ref_pat_everywhere`Jules Bertholet-2/+1
2024-05-06Auto merge of #124747 - MasterAwesome:master, r=davidtwcobors-0/+3
Support Result<T, E> across FFI when niche optimization can be used (v2) This PR is identical to #122253, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? ghost Original PR description: --- Allow allow enums like `Result<T, E>` to be used across FFI if the T/E can be niche optimized and the non-niche-optimized type is FFI safe. Implementation of https://github.com/rust-lang/rfcs/pull/3391 Tracking issue: https://github.com/rust-lang/rust/issues/110503 Additional ABI and codegen tests were added in https://github.com/rust-lang/rust/pull/115372
2024-05-05Rollup merge of #124749 - RossSmyth:stable_range, r=davidtwcoGuillaume Gomez-2/+2
Stabilize exclusive_range_pattern (v2) This PR is identical to #124459, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? ghost Original PR description: --- Stabilization report: https://github.com/rust-lang/rust/issues/37854#issuecomment-1842398130 FCP: https://github.com/rust-lang/rust/issues/37854#issuecomment-1872520294 Stabilization was blocked by a lint that was merged here: #118879 Documentation PR is here: rust-lang/reference#1484 `@rustbot` label +F-exclusive_range_pattern +T-lang
2024-05-04Implement do_not_recommend in the new solverMichael Goulet-1/+1
2024-05-03Rollup merge of #124480 - Enselic:on-broken-pipe, r=jieyouxuMichael Goulet-6/+0
Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...` In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward. So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature. Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization. Tracking issue: https://github.com/rust-lang/rust/issues/97889
2024-05-02Stabilize exclusive_rangeRoss Smyth-2/+2
2024-05-02Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`Martin Nordholts-6/+0
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern was raised related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward. So as a first step towards towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature. Another point was also raised, namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
2024-05-01Replace version placeholders for 1.79Mark Rousskov-14/+14
2024-05-01Stabilize `custom_code_classes_in_docs` featureGuillaume Gomez-2/+2
2024-04-28Add tracking issue and unstable book page for `"vectorcall"` ABIbeetrees-2/+2
2024-04-25debuginfo: Stabilize `-Z debug-macros`, `-Z collapse-macro-debuginfo` and ↵Vadim Petrochenkov-8/+5
`#[collapse_debuginfo]` `-Z debug-macros` is "stabilized" by enabling it by default and removing. `-Z collapse-macro-debuginfo` is stabilized as `-C collapse-macro-debuginfo`. It now supports all typical boolean values (`parse_opt_bool`) in addition to just yes/no. Default value of `collapse_debuginfo` was changed from `false` to `external` (i.e. collapsed if external, not collapsed if local). `#[collapse_debuginfo]` attribute without a value is no longer supported to avoid guessing the default.
2024-04-24Stabilise `inline_const`Gary Guo-2/+2
2024-04-24Add explicit syntax for coroutines instead of relying on closures having ↵Oli Scherer-0/+6
`yield` expressions