| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
|
|
`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.
|
|
|
|
Don't suggest converting `///` to `//` when expecting `,`
Fixes rust-lang/rust#142311
|
|
|
|
|
|
|
|
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`
|
|
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`````
|
|
r=oli-obk
Async drop - fix for StorageLive/StorageDead codegen for pinned future
Fixes: rust-lang/rust#140429, Fixes: rust-lang/rust#140531, Fixes: rust-lang/rust#141761, Fixes: rust-lang/rust#141409.
StorageLive/StorageDead codegen is corrected for pinned async drop future.
|
|
r=oli-obk,traviscross
Report never type lints in dependencies
This PR marks never type lints (`never_type_fallback_flowing_into_unsafe` & `dependency_on_unit_never_type_fallback`) to be included in cargo's reports / to be emitted when they happen in dependencies.
This PR is based on rust-lang/rust#141936
r? oli-obk
|
|
Remove wasm legacy abi
Closes https://github.com/rust-lang/rust/issues/122532
Closes https://github.com/rust-lang/rust/issues/138762
Fixes https://github.com/rust-lang/rust/issues/71871
https://github.com/rust-lang/rust/issues/88152
Fixes https://github.com/rust-lang/rust/issues/115666
Fixes https://github.com/rust-lang/rust/issues/129486
|
|
|
|
|
|
early linting: avoid redundant calls to `check_id`
An attempt to address the regression at https://github.com/rust-lang/rust/pull/142240#issuecomment-2964425460
r? `@oli-obk`
cc `@nnethercote` who might have a better understanding of the performance implications
|
|
|
|
|
|
|
|
|
|
shepmaster:mismatched-syntaxes-in-function-like-places, r=jieyouxu
Apply `mismatched-lifetime-syntaxes` to trait and extern functions
r? `@jieyouxu`
|
|
|
|
r=WaffleLapkin
Fix incorrect suggestion when calling an associated type with a type anchor
`sugg_span` here is the span of the call expression.
That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't)
r? ``@WaffleLapkin``
One commit with failing tests and one that fixes it for reviewability
closes rust-lang/rust#142473
|
|
variadic functions: remove list of supported ABIs from error
I think this list is problematic for multiple reasons:
- It is bound to go out-of-date as it is in a very different place from where we actually define which functions support varagrs (`fn supports_varargs`).
- Many of the ABIs we list only work on some targets; it makes no sense to mention "aapcs" as a possible ABI when building for x86_64. (This led to a lot of confusion in https://github.com/rust-lang/rust/issues/110505 where the author thought they should use "cdecl" and then were promptly told that "cdecl" is not a legal ABI on their target.)
- Typically, when the programmer wrote `extern "foobar"`, it is because they need the "foobar" ABI. It is of little use to tell them that there are other ABIs with which varargs would work.
Cc ``@workingjubilee``
|
|
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixes rust-lang/rust#79409
|
|
Temporary lifetime extension through tuple struct and tuple variant constructors
This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`.
Before:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended
```
After:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended
```
So, with this change, this works:
```rust
let a = Some(&String::from("hello")); // New: String lifetime now extended!
println!("{a:?}");
```
Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in:
```rust
let a = some_function(&String::from("hello")); // String not extended!
```
However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.
In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.
This needs a lang fcp.
---
More examples of what will work after this change:
```rust
let x = Person {
name: "Ferris",
job: Some(&Job { // `Job` now extended!
title: "Chief Rustacean",
organisation: "Acme Ltd.",
}),
};
dbg!(x);
```
```rust
let file = if use_stdout {
None
} else {
Some(&File::create("asdf")?) // `File` now extended!
};
set_logger(file);
```
```rust
use std::path::Component;
let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!
assert_eq!(path.components.first().unwrap(), c);
```
|
|
future
|
|
|
|
tests: Convert two handwritten minicores to add-core-stubs
|
|
Require generic params for const generic params
I think that was just an oversight when the support for them was added
r? `@BoxyUwU` or `@camelid`
fixes rust-lang/rust#137188
fixes rust-lang/rust#138166
fixes rust-lang/rust#138240
fixes rust-lang/rust#138266
fixes rust-lang/rust#138359
|
