| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
Like `Sized` diagnostics, sorting `MetaSized` and `PointeeSized`
diagnostics last prevents earlier more useful diagnostics from being
skipped because there has already been error tainting.
|
|
Given the necessary additions of bounds to these traits and their impls
in the standard library, it is necessary to add `MetaSized` bounds to
the obligation which is proven as part of checking for dyn
dispatchability.
|
|
`Sized` errors are currently stashed to improve diagnostics and this
must happen with `{Meta,Pointee}Sized` too to maintain diagnostic
output.
|
|
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.
|
|
Adding a sizedness supertrait shouldn't require multiple vtables so
shouldn't be linted against.
|
|
As core uses an extern type (`ptr::VTable`), the default `?Sized` to
`MetaSized` migration isn't sufficient, and some code that previously
accepted `VTable` needs relaxed to continue to accept extern types.
Similarly, the compiler uses many extern types in `rustc_codegen_llvm`
and in the `rustc_middle::ty::List` implementation (`OpaqueListContents`)
some bounds must be relaxed to continue to accept these types.
Unfortunately, due to the current inability to relax `Deref::Target`,
some of the bounds in the standard library are forced to be stricter than
they ideally would be.
|
|
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.
|
|
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.
|
|
Miri subtree update
r? `@ghost`
|
|
Use `LLVMIntrinsicGetDeclaration` to completely remove the hardcoded intrinsics list
Follow-up to rust-lang/rust#142259
This also needs a rustc-perf run, because `Intrinsic::getType` can be expensive
`@rustbot` label A-LLVM A-codegen T-compiler
r? `@workingjubilee`
cc `@nikic`
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#133952 (Remove wasm legacy abi)
- rust-lang/rust#134661 (Reduce precedence of expressions that have an outer attr)
- rust-lang/rust#141769 (Move metadata object generation for dylibs to the linker code )
- rust-lang/rust#141937 (Report never type lints in dependencies)
- rust-lang/rust#142347 (Async drop - fix for StorageLive/StorageDead codegen for pinned future)
- rust-lang/rust#142389 (Apply ABI attributes on return types in `rustc_codegen_cranelift`)
- rust-lang/rust#142470 (Add some missing mailmap entries)
- rust-lang/rust#142481 (Add `f16` inline asm support for LoongArch)
- rust-lang/rust#142499 (Remove check run bootstrap)
- rust-lang/rust#142543 (Suggest adding semicolon in user code rather than macro impl details)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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`
|
|
r=Kobzol
Remove check run bootstrap
This PR migrates all usage of check_run to new execution context api's.
r? `@Kobzol`
|
|
Add `f16` inline asm support for LoongArch
r? `````@Amanieu`````
|
|
Add some missing mailmap entries
|
|
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
|
|
r=workingjubilee,saethlin
Move metadata object generation for dylibs to the linker code
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
Prerequisite of https://github.com/rust-lang/rust/issues/96708.
|
|
Reduce precedence of expressions that have an outer attr
Previously, `-Zunpretty=expanded` would expand this program as follows:
```rust
#![feature(stmt_expr_attributes)]
macro_rules! repro {
($e:expr) => {
#[allow(deprecated)] $e
};
}
#[derive(Default)]
struct Thing {
#[deprecated]
field: i32,
}
fn main() {
let thing = Thing::default();
let _ = repro!(thing).field;
}
```
```rs
#![feature(prelude_import)]
#![feature(stmt_expr_attributes)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
struct Thing {
#[deprecated]
field: i32,
}
#[automatically_derived]
impl ::core::default::Default for Thing {
#[inline]
fn default() -> Thing {
Thing { field: ::core::default::Default::default() }
}
}
fn main() {
let thing = Thing::default();
let _ = #[allow(deprecated)] thing.field;
}
```
This is not the correct expansion. The correct output would have `(#[allow(deprecated)] thing).field` with the attribute applying only to `thing`, not to `thing.field`.
|
|
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
|
|
use `MixedBitSet` for borrows-in-scope dataflow analysis
The `Borrows` dataflow analysis uses a dense bitset, but a bitset supporting _some_ amount of sparseness is better suited for big functions with a big number of loans.
The cutoff between dense and chunked bitset is around 2K loans IIRC, and we could finesse that value if we wanted to, but as-is it happens to a couple of rustc-perf benchmarks (which IIRC are at least partially generated from macros and the likes.). It's a small win on these two, and shouldn't have any impact on the others.
r? `@matthewjasper`
|
|
|
|
|
|
jdonszelmann:attempt-to-mitigate-delayed-lint-perf-problems, r=oli-obk
collect delayed lints in hir_crate_items
r? `@oli-obk`
Attempt to mitigate perf problems in rust-lang/rust#138164
|
|
intrinsics list
|
|
Don't fold `ExternalConstraintsData` when it's empty
Probably useless, but let's see.
r? lcnr
|
|
Rustup
|
|
|
|
|
|
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
|
|
Do not clone Arc when hashing span.
Tiny improvement I was when trying to profile span hashing.
|
|
move fast reject into inner
to also fast reject inside of the folder
r? `@BoxyUwU`
|
|
rustdoc_json: reduce allocations
These commits reduce the number of allocations done for rustdoc_json, mostly by avoiding unnecessary clones.
Best reviewed one commit at a time.
r? `@aDotInTheVoid`
|
|
[perf] `GenericArgs`-related: Change asserts to debug asserts & use more slice interning over iterable interning
1. The 1st commit yields the following perf gains: [#142289 (comment)](https://github.com/rust-lang/rust/pull/142289#issuecomment-2964041303).
2. The 2nd commit might also have a minor positive perf impact, however that one wasn't tested in isolation.
For reference, the initial approach https://github.com/rust-lang/rust/commit/c7e6accd79d91fe5dec01a81499a08f9db280440 (results: https://github.com/rust-lang/rust/pull/142289#issuecomment-2961076587) had a lot more changes (apart from what's now contained in commit 1 and 2) which seemed to be perf irrelevant (cf. the partial countercheck in https://github.com/rust-lang/rust/commit/6f82bf1cfece61d32714fbfeecf8c5cf1356b3ae (results: https://github.com/rust-lang/rust/pull/142289#issuecomment-2968393647).
|
|
Simplify implementation of Rust intrinsics by using type parameters in the cache
The current implementation of intrinsics have a lot of duplication to handle different overloads of overloaded LLVM intrinsic. This PR uses the **base name and the type parameters** in the cache instead of the full, overloaded name. This has the benefit that `call_intrinsic` doesn't need to provide the full name, rather the type parameters (which is most of the time more available). This uses `LLVMIntrinsicCopyOverloadedName2` to get the overloaded name from the base name and the type parameters, and only uses it to declare the function.
(originally was part of rust-lang/rust#140763, split off later)
`@rustbot` label A-codegen A-LLVM
r? codegen
|
|
|
|
Rustup
|
|
shepmaster:mismatched-syntaxes-in-function-like-places, r=jieyouxu
Apply `mismatched-lifetime-syntaxes` to trait and extern functions
r? `@jieyouxu`
|
|
|
