| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Two places doing the same thing is enough to motivate me to extract this to a method :)
|
|
|
|
|
|
|
|
r=workingjubilee
c-variadic: allow c-variadic inherent and trait methods
tracking issue: https://github.com/rust-lang/rust/issues/44930
Continuing the work of https://github.com/rust-lang/rust/pull/146342, allow inherent and trait methods to be c-variadic. However, a trait that contains a c-variadic method is no longer dyn-compatible.
There is, presumably, some way to make c-variadic methods dyn-compatible. However currently, we don't have confidence that it'll work reliably: when methods from a `dyn` object are cast to a function pointer, a `ReifyShim` is created. If that shim is c-variadic, it would need to forward the C variable argument list.
That does appear to work, because the `va_list` is not represented in MIR at all in this case, so the registers from the call site are untouched by the shim and can be read by the actual implementation. That just does not seem like a solid implementation.
Also, intuitively, why would c-variadic function, primarily needed for FFI, need to be used with `dyn` objects at all? We can revisit this limitation if a need arises.
r? `@workingjubilee`
|
|
|
|
but a C-variadic method makes a trait dyn-incompatible. That is because
methods from dyn traits, when cast to a function pointer, create a shim.
That shim can't really forward the c-variadic arguments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
there is no reason this should not work, really, we're just cutting some scope for now
|
|
|
|
|
|
|
|
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
|
|
|
|
Lint buffering currently relies on a giant enum `BuiltinLintDiag`
containing all the lints that might potentially get buffered. In
addition to being an unwieldy enum in a central crate, this also makes
`rustc_lint_defs` a build bottleneck: it depends on various types from
various crates (with a steady pressure to add more), and many crates
depend on it.
Having all of these variants in a separate crate also prevents detecting
when a variant becomes unused, which we can do with a dedicated type
defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types
directly.
This requires boxing, but all of this is already on the slow path
(emitting an error).
Because the existing `BuiltinLintDiag` requires some additional types in
order to decorate some variants, which are only available later in
`rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn
LintDiagnostic` case and the `BuiltinLintDiag` case.
|
|
|
|
Gate static closures behind a parser feature
I'd like to gate `static ||` closures behind a feature gate, since we shouldn't allow people to take advantage of this syntax if it's currently unstable. Right now, since it's only rejected after ast lowering, it's accessible to macros.
Let's crater this to see if we can claw it back without breaking anyone's code.
|
|
Enforce correct number of arguments for `"x86-interrupt"` functions
Tracking issue: rust-lang/rust#40180
Partially fixes rust-lang/rust#132835
`````@rustbot````` label: +F-abi_x86_interrupt +A-LLVM +O-x86_64 +O-x86_32 +A-ABI
|
|
|
|
|
|
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field.
If the `inline` field is `Inline::Yes` then `had_parse_error` must be
`Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No`
variant. This makes it impossible to create the nonsensical combination
of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
|
|
fix: Reject async assoc fns of const traits/impls in ast_passes
Fixes rust-lang/rust#117629
|
|
|
|
r=davidtwco
compiler: Allow `extern "interrupt" fn() -> !`
While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited.
- Fixes rust-lang/rust#143072
|
|
|
|
|
|
This is a technically a breaking change for what can be parsed in
`#[cfg(false)]`.
|
|
|
|
|
|
Tweak auto trait errors
Make suggestions to remove params and super traits verbose and make spans more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
|
|
Make suggestions to remove params and super traits tool-only, and make
the suggestion span more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
|
|
|
|
|
|
|
|
|
|
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
|
|
Remove let_chains unstable feature
Per https://github.com/rust-lang/rust/issues/53667#issuecomment-3016742982 (but then I also noticed rust-lang/rust#140722)
This replaces the feature gate with a parser error that says let chains require 2024.
A lot of tests were using the unstable feature. I either added edition:2024 to the test or split out the parts that require 2024.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error)
- rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features)
- rust-lang/rust#140770 (add `extern "custom"` functions)
- rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches)
- rust-lang/rust#142248 (Add supported asm types for LoongArch32)
- rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`)
- rust-lang/rust#142274 (Update the stdarch submodule)
- rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`)
- rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library)
Failed merges:
- rust-lang/rust#140920 (Extract some shared code from codegen backend target feature handling)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
|
|
|
