Commit graph

956 commits

Author SHA1 Message Date
Jacob Pratt
4e4a93c2dd
Rollup merge of #131830 - hoodmane:emscripten-wasm-eh, r=workingjubilee
Add support for wasm exception handling to Emscripten target

This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
2025-01-06 22:04:13 -05:00
Hood Chatham
49c74234a7 Add support for wasm exception handling to Emscripten target
Gated behind an unstable `-Z emscripten-wasm-eh` flag
2025-01-06 10:29:54 +01:00
Jubilee
7cf3b96a83
Rollup merge of #135046 - RalfJung:rustc_box_intrinsic, r=compiler-errors
turn rustc_box into an intrinsic

I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
2025-01-04 07:57:33 -08:00
Ralf Jung
3cd3649c6c rustc_intrinsic: support functions without body; they are implicitly marked as must-be-overridden 2025-01-04 11:41:51 +01:00
Ralf Jung
ac9cb908ac turn rustc_box into an intrinsic 2025-01-03 12:01:31 +01:00
Zalathar
87c2f9a5be Revert "Auto merge of #130766 - clarfonthey:stable-coverage-attribute, r=wesleywiser"
This reverts commit 1d35638dc3, reversing
changes made to f23a80a4c2.
2024-12-23 12:30:37 +11:00
Lukas Markeffsky
42c00cb647 split up #[rustc_deny_explicit_impl] attribute
This commit splits the `#[rustc_deny_explicit_impl(implement_via_object = ...)]` attribute
into two attributes `#[rustc_deny_explicit_impl]` and `#[rustc_do_not_implement_via_object]`.

This allows us to have special traits that can have user-defined impls but do not have the
automatic trait impl for trait objects (`impl Trait for dyn Trait`).
2024-12-20 16:57:14 +01:00
Georg Semmler
dd31713c53
Stabilize #[diagnostic::do_not_recommend]
This commit seeks to stabilize the `#[diagnostic::do_not_recommend]`
attribute.
This attribute was first proposed as `#[do_not_recommend`] attribute in
RFC 2397 (https://github.com/rust-lang/rfcs/pull/2397). It gives the
crate authors the ability to not suggest to the compiler to not show
certain traits in it's error messages. With the presence of the
`#[diagnostic]` tool attribute namespace it was decided to move the
attribute there, as that lowers the amount of guarantees the compiler
needs to give about the exact way this influences error messages. It
turns the attribute into a hint which can be ignored. In addition to the
original proposed functionality this attribute now also hides the marked
trait in help messages ("This trait is implemented by: ").
The attribute does not accept any argument and can only be placed on
trait implementations. If it is placed somewhere else a lint warning is
emitted and the attribute is otherwise ignored. If an argument is
detected a lint warning is emitted and the argument is ignored. This
follows the rules outlined by the diagnostic namespace.

This attribute allows crates like diesel to improve their error messages
drastically. The most common example here is the following error
message:

```
error[E0277]: the trait bound `&str: Expression` is not satisfied
  --> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
   |
LL |     SelectInt.check("bar");
   |               ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
   |
   = help: the following other types implement trait `Expression`:
             Bound<T>
             SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
  --> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
   |
LL | impl<T, ST> AsExpression<ST> for T
   |             ^^^^^^^^^^^^^^^^     ^
LL | where
LL |     T: Expression<SqlType = ST>,
   |        ------------------------ unsatisfied trait bound introduced here
```

By applying the new attribute to the wild card trait implementation of
`AsExpression` for `T: Expression` the error message becomes:

```
error[E0277]: the trait bound `&str: AsExpression<Integer>` is not satisfied
  --> $DIR/as_expression.rs:55:15
   |
LL |     SelectInt.check("bar");
   |               ^^^^^ the trait `AsExpression<Integer>` is not implemented for `&str`
   |
   = help: the trait `AsExpression<Text>` is implemented for `&str`
   = help: for that trait implementation, expected `Text`, found `Integer`
```

which makes it much easier for users to understand that they are facing
a type mismatch.

Other explored example usages included

* This standard library error message: https://github.com/rust-lang/rust/pull/128008
* That bevy derived example:
e1f3068995/tests/ui/diagnostic_namespace/do_not_recommend/supress_suggestions_in_help.rs (No
more tuple pyramids)

Fixes #51992
2024-12-18 07:10:53 +01:00
Nicholas Nethercote
2620eb42d7 Re-export more rustc_span::symbol things from rustc_span.
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.

This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
2024-12-18 13:38:53 +11:00
ltdk
cb487cc2fa Stabilize #[coverage] attribute 2024-12-16 21:07:06 -05:00
Taiki Endo
56b8e66c66 Add m68k_target_feature 2024-12-15 15:26:50 +09:00
Michael Goulet
d714a22e7b (Re-)Implement impl_trait_in_bindings 2024-12-14 03:21:24 +00:00
bors
4a204bebdf Auto merge of #134269 - matthiaskrgr:rollup-fkshwux, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #133900 (Advent of `tests/ui` (misc cleanups and improvements) [1/N])
 - #133937 (Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them)
 - #133938 (`rustc_mir_dataflow` cleanups, including some renamings)
 - #134058 (interpret: reduce usage of TypingEnv::fully_monomorphized)
 - #134130 (Stop using driver queries in the public API)
 - #134140 (Add AST support for unsafe binders)
 - #134229 (Fix typos in docs on provenance)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-12-13 23:09:16 +00:00
bors
327c7ee436 Auto merge of #133099 - RalfJung:forbidden-hardfloat-features, r=workingjubilee
forbid toggling x87 and fpregs on hard-float targets

Part of https://github.com/rust-lang/rust/issues/116344, follow-up to https://github.com/rust-lang/rust/pull/129884:

The `x87`  target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](https://github.com/rust-lang/rust/issues/130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86).

Also fixes https://github.com/rust-lang/rust/issues/132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature.

The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure.

r? `@workingjubilee`
2024-12-13 19:43:00 +00:00
Matthias Krüger
5c9b227a3d
Rollup merge of #134140 - compiler-errors:unsafe-binders-ast, r=oli-obk
Add AST support for unsafe binders

I'm splitting up #130514 into pieces. It's impossible for me to keep up with a huge PR like that. I'll land type system support for this next, probably w/o MIR lowering, which will come later.

r? `@oli-obk`
cc `@BoxyUwU` and `@lcnr` who also may want to look at this, though this PR doesn't do too much yet
2024-12-13 17:25:31 +01:00
Michael Goulet
c605c84be8 Stabilize async closures 2024-12-13 00:04:56 +00:00
Michael Goulet
3f97c6be8d Add unwrap_unsafe_binder and wrap_unsafe_binder macro operators 2024-12-12 16:29:40 +00:00
Ralf Jung
d6ddc73dae forbid toggling x87 and fpregs on hard-float targets 2024-12-11 22:18:50 +01:00
Michael Goulet
3b05779626 Add feature gate, not working yet 2024-12-10 16:52:20 +00:00
Esteban Küber
9ac95c10c0 Introduce default_field_values feature
Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681.

Support default fields in enum struct variant

Allow default values in an enum struct variant definition:

```rust
pub enum Bar {
    Foo {
        bar: S = S,
        baz: i32 = 42 + 3,
    }
}
```

Allow using `..` without a base on an enum struct variant

```rust
Bar::Foo { .. }
```

`#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants.

Support `#[derive(Default)]` on enum struct variants with all defaulted fields

```rust
pub enum Bar {
    #[default]
    Foo {
        bar: S = S,
        baz: i32 = 42 + 3,
    }
}
```

Check for missing fields in typeck instead of mir_build.

Expand test with `const` param case (needs `generic_const_exprs` enabled).

Properly instantiate MIR const

The following works:

```rust
struct S<A> {
    a: Vec<A> = Vec::new(),
}
S::<i32> { .. }
```

Add lint for default fields that will always fail const-eval

We *allow* this to happen for API writers that might want to rely on users'
getting a compile error when using the default field, different to the error
that they would get when the field isn't default. We could change this to
*always* error instead of being a lint, if we wanted.

This will *not* catch errors for partially evaluated consts, like when the
expression relies on a const parameter.

Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`:

 - Suggest adding a base expression if there are missing fields.
 - Suggest enabling the feature if all the missing fields have optional values.
 - Suggest removing `..` if there are no missing fields.
2024-12-09 21:55:01 +00:00
Matthias Krüger
1868c8f66f
Rollup merge of #133424 - Nadrieril:guard-patterns-parsing, r=fee1-dead
Parse guard patterns

This implements the parsing of [RFC3637 Guard Patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see also [tracking issue](https://github.com/rust-lang/rust/issues/129967)). This PR is extracted from https://github.com/rust-lang/rust/pull/129996 with minor modifications.

cc `@max-niederman`
2024-12-08 17:18:50 +01:00
Ben Kimock
711c8cc690 Remove polymorphization 2024-12-06 16:42:09 -05:00
bors
3b382642ab Auto merge of #133818 - matthiaskrgr:rollup-iav1wq7, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #132937 (a release operation synchronizes with an acquire operation)
 - #133681 (improve TagEncoding::Niche docs, sanity check, and UB checks)
 - #133726 (Add `core::arch::breakpoint` and test)
 - #133768 (Remove `generic_associated_types_extended` feature gate)
 - #133811 ([AIX] change AIX default codemodel=large)
 - #133812 (Update wasm-component-ld to 0.5.11)
 - #133813 (compiletest: explain that UI tests are expected not to compile by default)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-12-04 00:47:09 +00:00
Michael Goulet
f91fd0cb87 Remove generic_associated_types_extended feature gate 2024-12-03 16:34:44 +00:00
Michael Goulet
59e3e8934e Gate async fn trait bound modifier on async_trait_bounds 2024-12-02 16:50:44 +00:00
许杰友 Jieyou Xu (Joe)
dd99f11ef8
Rollup merge of #116161 - Soveu:varargs2, r=cjgillot
Stabilize `extended_varargs_abi_support`

I think that is everything? If there is any documentation regarding `extern` and/or varargs to correct, let me know, some quick greps suggest that there might be none.

Tracking issue: https://github.com/rust-lang/rust/issues/100189
2024-11-30 12:56:50 +08:00
Soveu
685f189b43 Stabilize extended_varargs_abi_support 2024-11-27 22:21:33 +01:00
Boxy
174ad448c7 replace placeholder version 2024-11-27 12:10:21 +00:00
Matthias Krüger
3f86eddf83
Rollup merge of #131664 - taiki-e:s390x-asm-vreg-inout, r=Amanieu
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.

This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |

This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313

In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.

Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.

cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm

`@rustbot` label +O-SystemZ +A-inline-assembly
2024-11-25 07:01:37 +01:00
Max Niederman
f8e50d8736 add guard_patterns unstable feature, without unstable book chapter for now 2024-11-24 18:08:09 +01:00
Gary Guo
0178ba2c25 Make asm_goto_with_outputs a separate feature gate 2024-11-24 15:24:01 +00:00
Taiki Endo
c024d8ccdf Make s390x non-clobber-only vector register support unstable 2024-11-24 21:42:22 +09:00
bors
6e1c11591f Auto merge of #132915 - veluca93:unsafe-fields, r=jswrenn
Implement the unsafe-fields RFC.

RFC: rust-lang/rfcs#3458

Tracking:

- https://github.com/rust-lang/rust/issues/132922

r? jswrenn
2024-11-23 07:47:52 +00:00
Michael Goulet
69a38de977 Check drop is trivial before checking ty needs drop 2024-11-22 17:01:02 +00:00
Michael Goulet
2088260852 Gate const drop behind const_destruct feature, and fix const_precise_live_drops post-drop-elaboration check 2024-11-22 16:54:40 +00:00
Luca Versari
9022bb2d6f Implement the unsafe-fields RFC.
Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
2024-11-21 19:32:07 +01:00
Matthias Krüger
fe5403f517
Rollup merge of #130236 - yaahc:unstable-feature-usage, r=estebank
unstable feature usage metrics

example output

```
test-lib on  master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cat src/lib.rs
───────┬───────────────────────────────────────────────────────
       │ File: src/lib.rs
───────┼───────────────────────────────────────────────────────
   1   │ #![feature(unix_set_mark)]
   2   │ pub fn add(left: u64, right: u64) -> u64 {
   3   │     left + right
   4   │ }
   5   │
   6   │ #[cfg(test)]
   7   │ mod tests {
   8   │     use super::*;
   9   │
  10   │     #[test]
  11   │     fn it_works() {
  12   │         let result = add(2, 2);
  13   │         assert_eq!(result, 4);
  14   │     }
  15   │ }
───────┴───────────────────────────────────────────────────────

test-lib on  master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cargo +stage1 rustc -- -Zmetrics-dir=$PWD/metrics
   Compiling test-lib v0.1.0 (/home/yaahc/tmp/test-lib)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s

test-lib on  master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cat metrics/unstable_feature_usage.json
───────┬─────────────────────────────────────────────────────────────────────
       │ File: metrics/unstable_feature_usage.json
───────┼─────────────────────────────────────────────────────────────────────
   1   │ {"lib_features":[{"symbol":"unix_set_mark"}],"lang_features":[]}
   ```

   related to https://github.com/rust-lang/rust/issues/129485
2024-11-21 11:58:36 +01:00
Jane Losare-Lusby
dc97db105a unstable feature usage metrics 2024-11-20 11:31:40 -08:00
Jacob Pratt
25dc4d0394
Rollup merge of #132732 - gavincrawford:as_ptr_attribute, r=Urgau
Use attributes for `dangling_pointers_from_temporaries` lint

Checking for dangling pointers by function name isn't ideal, and leaves out certain pointer-returning methods that don't follow the `as_ptr` naming convention. Using an attribute for this lint cleans things up and allows more thorough coverage of other methods, such as `UnsafeCell::get()`.
2024-11-20 01:54:24 -05:00
Noah Lev
59e339f766 Introduce min_generic_const_args and directly represent paths
Co-authored-by: Boxy UwU <rust@boxyuwu.dev>
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
2024-11-19 05:07:43 +00:00
Jacob Pratt
72a8d536ef
Rollup merge of #133142 - RalfJung:naming-is-hard, r=compiler-errors
rename rustc_const_stable_intrinsic -> rustc_intrinsic_const_stable_indirect

In https://github.com/rust-lang/rust/pull/120370 this name caused confusion as the author thought the intrinsic was stable. So let's try a different name...

If we can land this before the beta cutoff we can avoid needing `cfg(bootstrap)` for this. ;)
Cc `@compiler-errors` `@saethlin`
2024-11-18 02:24:35 -05:00
Ralf Jung
9d4b1b2db4 rename rustc_const_stable_intrinsic -> rustc_intrinsic_const_stable_indirect 2024-11-18 07:47:44 +01:00
Jieyou Xu
202caa7c57 Add RUSTC_BOOTSTRAP=-1 to make rustc pretend as stable compiler 2024-11-17 19:59:52 +08:00
gavincrawford
5f443df404
Add #[rustc_as_ptr] attribute 2024-11-11 13:33:48 -07:00
Matthias Krüger
b9d4ef16c9
Rollup merge of #132552 - taiki-e:sparc-target-feature, r=workingjubilee
Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file

This adds the following three unstable target features:

- `v9`: SPARC-V9 instructions ([LLVM definition][sparc-v9])
  - Relevant to https://github.com/rust-lang/rust/pull/131222#issuecomment-2453310963
  - Relevant to https://github.com/rust-lang/rust/pull/132472#discussion_r1832606081
  - This is also needed to implement https://github.com/taiki-e/atomic-maybe-uninit/pull/31 (depends on inline assembly support) more robustly.
- `v8plus`: SPARC-V8+ ABI ([LLVM definition][sparc-v8plus])
  - This is added in LLVM 20. In LLVM 19 and older, it is emulated to work the same way as LLVM in each LLVM version.
  - See https://github.com/rust-lang/rust/issues/132585#issuecomment-2453926257 for more.
- `leoncasa`: CASA instruction[^1] of LEON3 and LEON4 processors ([LLVM definition][sparc-leoncasa], LLVM feature name: `hasleoncasa`)
  - This is needed to implement https://github.com/taiki-e/atomic-maybe-uninit/pull/31 (depends on inline assembly support) more robustly.

[^1]: Atomic CAS instruction

[sparc-v9]: f5e4ffaa49/llvm/lib/Target/Sparc/Sparc.td (L37-L39)
[sparc-v8plus]: f5e4ffaa49/llvm/lib/Target/Sparc/Sparc.td (L37-L39)
[sparc-leoncasa]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/LeonFeatures.td#L32-L37
2024-11-09 10:52:03 +01:00
Taiki Endo
400a690b5f Add v9 and leoncasa target feature to sparc 2024-11-09 03:17:24 +09:00
Ralf Jung
e3010e84db remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead 2024-11-08 09:16:00 +01:00
Ralf Jung
1f0ed2b0f5 add new rustc_const_stable_intrinsic attribute for const-stable intrinsics 2024-11-04 23:27:46 +01:00
Michael Goulet
0b5ddf30eb Yeet effects feature 2024-11-03 18:59:31 +00:00
Matthias Krüger
5d6c49938e
Rollup merge of #131984 - dingxiangfei2009:stabilize-if-let-rescope, r=traviscross,lcnr
Stabilize if_let_rescope

Close #131154
Tracked by #124085
2024-10-29 18:38:57 +01:00