| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
properly elaborate effects implied bounds for super traits
Summary: This PR makes it so that we elaborate `<T as Tr>::Fx: EffectsCompat<somebool>` into `<T as SuperTr>::Fx: EffectsCompat<somebool>` when we know that `trait Tr: ~const SuperTr`.
Some discussion at https://github.com/rust-lang/project-const-traits/issues/2.
r? project-const-traits
`@rust-lang/project-const-traits:` how do we feel about this approach?
|
|
try to get rid of mir::Const::normalize
It was easy to make this compile, let's see if anything breaks...
r? `@compiler-errors`
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #130718 (Cleanup some known-bug issues)
- #130730 (Reorganize Test Headers)
- #130826 (Compiler: Rename "object safe" to "dyn compatible")
- #130915 (fix typo in triagebot.toml)
- #130926 (Update cc to 1.1.22 in library/)
- #130932 (etc: Add sample rust-analyzer configs for eglot & helix)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=compiler-errors
Compiler: Rename "object safe" to "dyn compatible"
Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118.
Tracking issue: https://github.com/rust-lang/rust/issues/130852
Excludes `compiler/rustc_codegen_cranelift` (to be filed separately).
Includes Stable MIR.
Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language).
r? ghost
|
|
|
|
Like #130865 did for the standard library, we can use `&raw` in the
compiler now that stage0 supports it. Also like the other issue, I did
not make any doc or test changes at this time.
|
|
|
|
Add `File` constructors that return files wrapped with a buffer
In addition to the light convenience, these are intended to raise visibility that buffering is something you should consider when opening a file, since unbuffered I/O is a common performance footgun to Rust newcomers.
ACP: https://github.com/rust-lang/libs-team/issues/446
Tracking Issue: #130804
|
|
Separate collection of crate-local inherent impls from error tracking
#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until #121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.
Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in #127798.
This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.
This fixes #127798.
|
|
|
|
|
|
|
|
This changes the remaining span for the cast, because the new `Cast`
category has a higher priority (lower `Ord`) than the old `Coercion`
category, so we no longer report the region error for the "unsizing"
coercion from `*const Trait` to itself.
|
|
|
|
|
|
|
|
Check vtable projections for validity in miri
Currently, miri does not catch when we transmute `dyn Trait<Assoc = A>` to `dyn Trait<Assoc = B>`. This PR implements such a check, and fixes https://github.com/rust-lang/miri/issues/3905.
To do this, we modify `GlobalAlloc::VTable` to contain the *whole* list of `PolyExistentialPredicate`, and then modify `check_vtable_for_type` to validate the `PolyExistentialProjection`s of the vtable, along with the principal trait that was already being validated.
cc ``@RalfJung``
r? ``@lcnr`` or types
I also tweaked the diagnostics a bit.
---
**Open question:** We don't validate the auto traits. You can transmute `dyn Foo` into `dyn Foo + Send`. Should we check that? We currently have a test that *exercises* this as not being UB:
https://github.com/rust-lang/rust/blob/6c6d210089e4589afee37271862b9f88ba1d7755/src/tools/miri/tests/pass/dyn-upcast.rs#L14-L20
I'm not actually sure if we ever decided that's actually UB or not 🤔
We could perhaps still check that the underlying type of the object (i.e. the concrete type that was unsized) implements the auto traits, to catch UB like:
```rust
fn main() {
let x: &dyn Trait = &std::ptr::null_mut::<()>();
let _: &(dyn Trait + Send) = std::mem::transmute(x);
//~^ this vtable is not allocated for a type that is `Send`!
}
```
|
|
Skip query in get_parent_item when possible.
For HirIds with a non-zero item local id, `self.parent_owner_iter(hir_id).next()` just returns the same HirId with the item local id set to 0, but also does a query to retrieve the Node which is ignored here, which seems wasteful.
|
|
|
|
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
|
|
add `extern "C-cmse-nonsecure-entry" fn`
tracking issue #75835
in https://github.com/rust-lang/rust/issues/75835#issuecomment-1183517255 it was decided that using an abi, rather than an attribute, was the right way to go for this feature.
This PR adds that ABI and removes the `#[cmse_nonsecure_entry]` attribute. All relevant tests have been updated, some are now obsolete and have been removed.
Error 0775 is no longer generated. It contains the list of targets that support the CMSE feature, and maybe we want to still use this? right now a generic "this abi is not supported on this platform" error is returned when this abi is used on an unsupported platform. On the other hand, users of this abi are likely to be experienced rust users, so maybe the generic error is good enough.
|
|
Correct outdated object size limit
The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.
The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.
try-job: i686-msvc
try-job: test-various
|
|
Don't alloca for unused locals
We already have a concept of mono-unreachable basic blocks; this is primarily useful for ensuring that we do not compile code under an `if false`. But since we never gave locals the same analysis, a large local only used under an `if false` will still have stack space allocated for it.
There are 3 places we traverse MIR during monomorphization: Inside the collector, `non_ssa_locals`, and the walk to generate code. Unfortunately, https://github.com/rust-lang/rust/pull/129283#issuecomment-2297925578 indicates that we cannot afford the expense of tracking reachable locals during the collector's traversal, so we do need at least two mono-reachable traversals. And of course caching is of no help here because the benchmarks that regress are incr-unchanged; they don't do any codegen.
This fixes the second problem in https://github.com/rust-lang/rust/issues/129282, and brings us anther step toward `const if` at home.
|
|
|
|
|
|
|
|
|
|
|
|
Begin experimental support for pin reborrowing
This commit adds basic support for reborrowing `Pin` types in argument position. At the moment it only supports reborrowing `Pin<&mut T>` as `Pin<&mut T>` by inserting a call to `Pin::as_mut()`, and only in argument position (not as the receiver in a method call).
This PR makes the following example compile:
```rust
#![feature(pin_ergonomics)]
fn foo(_: Pin<&mut Foo>) {
}
fn bar(mut x: Pin<&mut Foo>) {
foo(x);
foo(x);
}
```
Previously, you would have had to write `bar` as:
```rust
fn bar(mut x: Pin<&mut Foo>) {
foo(x.as_mut());
foo(x);
}
```
Tracking:
- #130494
r? `@compiler-errors`
|
|
|
|
|
|
Generating a call to `as_mut()` let to more restrictive borrows than
what reborrowing usually gives us. Instead, we change the desugaring to
reborrow the pin internals directly which makes things more expressive.
|
|
|
|
This commit adds basic support for reborrowing `Pin` types in argument
position. At the moment it only supports reborrowing `Pin<&mut T>` as
`Pin<&mut T>` by inserting a call to `Pin::as_mut()`, and only in
argument position (not as the receiver in a method call).
|
|
Cleanup codegen traits
The traits governing codegen are quite complicated and hard to follow. This PR cleans them up a bit.
r? `@bjorn3`
|
|
methods
|
|
layout computation: gracefully handle unsized types in unexpected locations
This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error.
Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`.
The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised.
implements https://github.com/rust-lang/rust/pull/123169#issuecomment-2025788480
r? `@compiler-errors` or compiler
fixes https://github.com/rust-lang/rust/issues/123134
fixes https://github.com/rust-lang/rust/issues/124182
fixes https://github.com/rust-lang/rust/issues/126939
fixes https://github.com/rust-lang/rust/issues/127737
|
|
This avoids some repetitive boilerplate code.
|
|
|
|
|
|
|
|
Don't use `typeck_root_def_id` in codegen for finding closure's root
Generating debuginfo in codegen currently peels off all the closure-specific generics (which presumably is done because they're redundant). This doesn't currently work correctly for the bodies we synthesize for async closures's returned coroutines (#128506), leading to #129702.
Specifically, `typeck_root_def_id` for some `DefKind::SyntheticCoroutineBody` just returns itself (because it loops while `is_typeck_child` is `true`, and that returns `false` for this defkind), which means we don't end up peeling off the coroutine-specific generics, and we end up encountering an otherwise unreachable `CoroutineWitness` type leading to an ICE.
This PR fixes `is_typeck_child` to consider `DefKind::SyntheticCorotuineBody` to be a typeck child, fixing `typeck_root_def_id` and suppressing this debuginfo bug.
Fixes #129702
|
