| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Revert overeager warning for misuse of `--print native-static-libs`
In a PR to emit warnings on misuse of `--print native-static-libs`, we did not consider the matter of composing parts of build systems. If you are not directly invoking rustc, it can be difficult to know when you will in fact compile a staticlib, so making sure uses `--print native-static-lib` correctly can be just a nuisance.
Next cycle we can reland a slightly more narrowly focused variant or one that focuses on `--emit` instead of `--print native-static-libs`. But in its current state, I am not sure the warning is very useful.
|
|
Make sure to propagate result from `visit_expr_fields`
We weren't propagating the `ControlFlow::Break` out of a struct field, which means that the solution implemented in rust-lang/rust#130443 didn't work for nested fields.
Fixes rust-lang/rust#142525.
|
|
Handle same-crate macro for borrowck semicolon suggestion
Handles https://github.com/rust-lang/rust/pull/142543#discussion_r2149545623
cc ``@m-ou-se``
r? ``@fmease``
|
|
Reject union default field values
Fixes rust-lang/rust#142555.
The [`default_field_values` RFC][rfc] does not specify that default field values may be used on `union`s, and it's not clear how default field values may be used with `union`s without an design extension to the RFC. So, for now, reject trying to use default field values with `union`s.
### Review notes
- The first commit adds the `union` with default field values test case to `tests/ui/structs/default-field-values/failures.rs`, where `union`s with default field values are currently accepted.
- The second commit rejects trying to supply default field values to `union` definitions.
- When `default_field_values` feature gate is disabled, we show the feature gate error when the user tries to write `union`s with default field values. When the feature gate is enabled, we reject this usage with
> unions cannot have default field values
``@rustbot`` label: +F-default_field_values
[rfc]: https://rust-lang.github.io/rfcs/3681-default-field-values.html
|
|
|
|
|
|
unwind mechanism
|
|
this is one-time initialization data, it can just
be a function parameter.
we also move the json parsing into createSrcSidebar
to save a few bytes.
|
|
|
|
As before, updating types using extern types to use `PointeeSized`
bounds.
|
|
Some rustdoc tests are `no_core` and need to have `MetaSized` and
`PointeeSized` added to them.
|
|
`nominal_obligations` calls `predicates_of` on a `Sized` obligation,
effectively elaborating the trait and making the well-formedness checking
machinery do a bunch of extra work checking a `MetaSized` obligation is
well-formed, but given that both `Sized` and `MetaSized` are built-ins,
if `Sized` is otherwise well-formed, so `MetaSized` will be.
|
|
As a performance optimization, skip elaborating the supertraits of
`Sized`, and if a `MetaSized` obligation is being checked, then look for
a `Sized` predicate in the parameter environment. This makes the
`ParamEnv` smaller which should improve compiler performance as it avoids
all the iteration over the larger `ParamEnv`.
|
|
These tests just need blessing, they don't have any interesting behaviour
changes.
Some of these tests have new errors because `LegacyReceiver` cannot be
proven to be implemented now that it is also testing for `MetaSized` -
but this is just a consequence of the other errors in the test.
|
|
This test case is a reduction from the `hwc` crate on GitHub, following a
crater run. It passes with the next solver but fails on the current
solver due to a known limitation of the current solver. It starts fails
on the current solver with the `sized_hierarchy` changes because `?Sized`
is now a proper bound.
|
|
It seems like generics from `non_lifetime_binders` don't have any default
bounds like normal generics, so all of the `?Sized` relaxations need
to be further relaxed with `PointeeSized` for this test to be the
equivalent of before.
|
|
With the addition of new bounds to the unconstrained parameters, there
are more errors which just need blessed.
|
|
These tests necessarily need to change now that `?Sized` is not
sufficient to accept extern types and `PointeeSized` is now necessary. In
addition, the `size_of_val`/`align_of_val` test can now be changed to
expect an error.
|
|
When `sized_hierarchy` is enabled, rustc should print `MetaSized` or
`PointeeSized` instead of `?Sized` in opaques.
|
|
When printing impl headers in a diagnostic, the compiler has to account
for `?Sized` implying `MetaSized` and new `MetaSized` and `PointeeSized`
bounds.
|
|
With `MetaSized` bounds replacing `?Sized` and being added as a
supertrait, the same relaxations applied to the standard library must be
applied to minicore.
|
|
Opting-out of `Sized` with `?Sized` is now equivalent to adding a
`MetaSized` bound, and adding a `MetaSized` or `PointeeSized` bound
is equivalent to removing the default `Sized` bound - this commit
implements this change in `rustc_hir_analysis::hir_ty_lowering`.
`MetaSized` is also added as a supertrait of all traits, as this is
necessary to preserve backwards compatibility.
Unfortunately, non-global where clauses being preferred over item bounds
(where `PointeeSized` bounds would be proven) - which can result in
errors when a `PointeeSized` supertrait/bound/predicate is added to some
items. Rather than `PointeeSized` being a bound on everything, it can
be the absence of a bound on everything, as `?Sized` was.
|
|
As before, add `MetaSized` and `PointeeSized` traits to all of the
non-minicore `no_core` tests so that they don't fail for lack of
language items.
|
|
In a PR to emit warnings on misuse of `--print native-static-libs`,
we did not consider the matter of composing parts of build systems.
If you are not directly invoking rustc, it can be difficult to know
when you will in fact compile a staticlib, so making sure everyone
uses `--print native-static-lib` correctly can be just a nuisance.
This reverts the following commits:
- f66787a08d57dc1296619b314d2be596085bfeef
- 72a9219e82c157041bfc8dfd378c9cb2b09c0650
- 98bb597c05c32365abbd6898f278b097352774ed
- c59b70841c36277464b51161e3fcf12dfcb667e0
Next cycle we can reland a slightly more narrowly focused variant or one
that focuses on `--emit` instead of `--print native-static-libs`.
But in its current state, I am not sure the warning is very useful.
|
|
|
|
Test naked asm for wasm32-unknown-unknown
cc https://github.com/rust-lang/rust/pull/133952#discussion_r2148924872
|
|
ignore `run-make` tests that need `std` on targets without `std`
In particular, anything that includes `none` in the target triple, and `nvptx64-nvidia-cuda`. Right now we don't cross-compile the `run-make` tests, but we want to in the future.
This uses `//@ needs-target-std` introduced in https://github.com/rust-lang/rust/pull/142297.
Useful for https://github.com/rust-lang/rust/pull/139244 and https://github.com/rust-lang/rust/pull/141856.
The modified files are based on running https://github.com/rust-lang/rust/pull/141856 locally. It might be that https://github.com/rust-lang/rust/pull/139244 uncovers some additional files, but that PR needs to be rebased (though actually I'd advice to rebase the non-test changes onto this PR, probably faster that way).
r? ``@jieyouxu``
<details>
<summary>vim notes for future me</summary>
Make a file with lines like this
```
/home/folkertdev/rust/rust/tests/run-make/export/disambiguator/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/invalid-so/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/no-builtins-attribute/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/export/extern-opt/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/link-dedup/rmake.rs:1:1
```
then
```
:set errorformat=%f:%l:%c
:cfile /tmp/files-to-fix.txt
```
```
:copen
:cnext
:cprev
```
are your friends
</details>
|
|
Don't suggest converting `///` to `//` when expecting `,`
Fixes rust-lang/rust#142311
|
|
Fix RISC-V C function ABI when passing/returning structs containing floats
RISC-V passes structs containing only one or two floats (or a float and integer pair) in registers, as long as the individual floats/integers fit in a single corresponding register (see [the ABI specification](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0/riscv-abi.pdf) for details). Before this PR, Rust would not check what offset the second float/integer was at, instead assuming that it was at the standard offset for its default alignment. However, as the offset can be affected by `#[repr(align(N))]` and `#[repr(packed)]`, this caused miscompilations (see #115609). To fix this, this PR introduces a `rest_offset` field to `CastTarget` that can be used to explicitly specify at what offset the `rest` part of the cast is located at.
While fixing this, I discovered another bug: the size of the cast target was being used as the size of the MIR return place (when the function was using a `PassMode::Cast` return type). However, the cast target is allowed to be smaller than the size of the actual type, causing a miscompilation. This PR fixes this issue by using the largest of the size of the type and the size of the cast target as the size of the MIR return place, ensuring all reads/writes will be inbounds.
Fixes the RISC-V part of #115609.
cc target maintainers of `riscv64gc-unknown-linux-gnu`: `@kito-cheng` `@michaelmaitland` `@robin-randhawa-sifive` `@topperc`
r? `@workingjubilee`
|
|
|
|
|
|
|
|
missing `,` in list
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Add `MetaSized` and `PointeeSized` to minicore so that fewer tests fail
from missing language items.
|
|
Expand the automatic implementation of `MetaSized` and `PointeeSized` so
that it is also implemented on non-`Sized` types, just not `ty::Foreign`
(extern type).
|
|
Introduce the `MetaSized` and `PointeeSized` traits as supertraits of
`Sized` and initially implement it on everything that currently
implements `Sized` to isolate any changes that simply adding the
traits introduces.
|
|
|
|
|
|
Most likely caused by updating unicode-width v0.2.0 -> v0.2.1,
the change seems reasonable enough.
|
|
In particular, there should be no additional errors (default field
values for `union` fields are currently erroneously accepted).
|
|
|
|
|
|
|
|
|
|
|
|
Suggest adding semicolon in user code rather than macro impl details
This PR tries to find the right span (by peeling expansion) so that the suggestion for adding a semicolon is suggested in user code rather than in the expanded code (in the example a macro impl).
Fixes rust-lang/rust#139049
r? `@fmease`
|
|
Add `f16` inline asm support for LoongArch
r? `````@Amanieu`````
|
|
Apply ABI attributes on return types in `rustc_codegen_cranelift`
- The [x86-64 System V ABI standard](https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build) doesn't sign/zero-extend integer arguments or return types.
- But the de-facto standard as implemented by Clang and GCC is to sign/zero-extend arguments to 32 bits (but not return types).
- Additionally, Apple targets [sign/zero-extend both arguments and return values to 32 bits](https://developer.apple.com/documentation/xcode/writing-64-bit-intel-code-for-apple-platforms#Pass-arguments-to-functions-correctly).
- However, the `rustc_target` ABI adjustment code currently [unconditionally extends both arguments and return values to 32 bits](https://github.com/rust-lang/rust/blame/e703dff8fe220b78195c53478e83fb2f68d8499c/compiler/rustc_target/src/callconv/x86_64.rs#L240) on all targets.
- This doesn't cause a miscompilation when compiling with LLVM as LLVM will ignore the `signext`/`zeroext` attribute when applied to return types on non-Apple x86-64 targets.
- Cranelift, however, does not have a similar special case, requiring `rustc` to set the argument extension attribute correctly.
- However, `rustc_codegen_cranelift` doesn't currently apply ABI attributes to return types at all, meaning `rustc_codegen_cranelift` will currently miscompile `i8`/`u8`/`i16`/`u16` returns on x86-64 Apple targets as those targets require sign/zero-extension of return types.
This PR fixes the bug(s) by making the `rustc_target` x86-64 System V ABI only mark return types as sign/zero-extended on Apple platforms, while also making `rustc_codegen_cranelift` apply ABI attributes to return types. The RISC-V and s390x C ABIs also require sign/zero extension of return types, so this will fix those targets when building with `rustc_codegen_cranelift` too.
r? `````@bjorn3`````
|
