| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove support for `dyn*` from the compiler
This PR removes support for `dyn*` (https://github.com/rust-lang/rust/issues/102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).
It doesn't seem like we are going to need `dyn*` types -- even in an not-exposed-to-the-user way[^1] -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of `dyn*` types, I don't really see a compelling reason to have to maintain their implementation in the compiler.
[^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`.
We've learned quite a lot from `dyn*`, but I think at this point its current behavior leads to more questions than answers. For example, `dyn*` support today remains somewhat fragile; it ICEs in many cases where the current "normal" `dyn Trait` types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.
```rust
#![feature(dyn_star)]
trait Foo {
fn hello(self);
}
impl Foo for usize {
fn hello(self) {
println!("hello, world");
}
}
fn main() {
let x: dyn* Foo = 1usize;
x.hello();
}
```
And:
```rust
#![feature(dyn_star)]
trait Trait {
type Out where Self: Sized;
}
fn main() {
let x: <dyn* Trait as Trait>::Out;
}
```
...and probably many more problems having to do with the intersection of dyn-compatibility and `Self: Sized` bounds that I was too lazy to look into like:
* GATs
* Methods with invalid signatures
* Associated consts
Generally, `dyn*` types also end up getting in the way of working with [normal `dyn` types](https://github.com/rust-lang/rust/issues/102425#issuecomment-1712604409) to an extent that IMO outweighs the benefit of experimentation.
I recognize that there are probably other, more creative usages of `dyn*` that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between `dyn*` and dyn-compatibility before we think about reimplementing them in the type system.
---
I'm planning on removing the `DynKind` enum and the `PointerLike` built-in trait from the compiler after this PR lands.
Closes rust-lang/rust#102425.
cc `@eholk` `@rust-lang/lang` `@rust-lang/types`
Closes rust-lang/rust#116979.
Closes rust-lang/rust#119694.
Closes rust-lang/rust#134591.
Closes rust-lang/rust#104800.
|
|
Remove support for `dyn*` from the compiler
This PR removes support for `dyn*` (https://github.com/rust-lang/rust/issues/102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).
It doesn't seem like we are going to need `dyn*` types -- even in an not-exposed-to-the-user way[^1] -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of `dyn*` types, I don't really see a compelling reason to have to maintain their implementation in the compiler.
[^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`.
We've learned quite a lot from `dyn*`, but I think at this point its current behavior leads to more questions than answers. For example, `dyn*` support today remains somewhat fragile; it ICEs in many cases where the current "normal" `dyn Trait` types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.
```rust
#![feature(dyn_star)]
trait Foo {
fn hello(self);
}
impl Foo for usize {
fn hello(self) {
println!("hello, world");
}
}
fn main() {
let x: dyn* Foo = 1usize;
x.hello();
}
```
And:
```rust
#![feature(dyn_star)]
trait Trait {
type Out where Self: Sized;
}
fn main() {
let x: <dyn* Trait as Trait>::Out;
}
```
...and probably many more problems having to do with the intersection of dyn-compatibility and `Self: Sized` bounds that I was too lazy to look into like:
* GATs
* Methods with invalid signatures
* Associated consts
Generally, `dyn*` types also end up getting in the way of working with [normal `dyn` types](https://github.com/rust-lang/rust/issues/102425#issuecomment-1712604409) to an extent that IMO outweighs the benefit of experimentation.
I recognize that there are probably other, more creative usages of `dyn*` that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between `dyn*` and dyn-compatibility before we think about reimplementing them in the type system.
---
I'm planning on removing the `DynKind` enum and the `PointerLike` built-in trait from the compiler after this PR lands.
Closes rust-lang/rust#102425.
cc `@eholk` `@rust-lang/lang` `@rust-lang/types`
Closes rust-lang/rust#116979.
Closes rust-lang/rust#119694.
Closes rust-lang/rust#134591.
Closes rust-lang/rust#104800.
|
|
When encountering `&str::from("value")` do not suggest `&&str::from("value")`.
Fix #132041.
|
|
|
|
|
|
|
|
|
|
Closes rust-lang/rust-clippy#15143
Covering edge cases missed in rust-lang/rust-clippy#15016
changelog: [`std-instead-of-core`] fix FP when not all items come from
the new crate
|
|
|
|
|
|
|
|
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
|
|
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#136801 (Implement `Random` for tuple)
- rust-lang/rust#141867 (Describe Future invariants more precisely)
- rust-lang/rust#142760 (docs(fs): Touch up grammar on lock api)
- rust-lang/rust#143181 (Improve testing and error messages for malformed attributes)
- rust-lang/rust#143210 (`tests/ui`: A New Order [19/N] )
- rust-lang/rust#143212 (`tests/ui`: A New Order [20/N])
- rust-lang/rust#143230 ([COMPILETEST-UNTANGLE 2/N] Make some compiletest errors/warnings/help more visually obvious)
- rust-lang/rust#143240 (Port `#[rustc_object_lifetime_default]` to the new attribute parsing …)
- rust-lang/rust#143255 (Do not enable LLD by default in the dist profile)
- rust-lang/rust#143262 (mir: Mark `Statement` and `BasicBlockData` as `#[non_exhaustive]`)
- rust-lang/rust#143269 (bootstrap: make comment more clear)
- rust-lang/rust#143279 (Remove `ItemKind::descr` method)
Failed merges:
- rust-lang/rust#143237 (Port `#[no_implicit_prelude]` to the new attribute parsing infrastructure)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also applies to `Vec::into_raw_parts`.
The expectation is that you can round-trip these methods with
`from_raw`, but this is only true when using the global allocator. With
custom allocators you should instead be using
`into_raw_with_allocator` and `from_raw_in`.
The implementation of `Box::leak` is changed to use
`Box::into_raw_with_allocator` and explicitly leak the allocator (which
was already the existing behavior). This is because, for `leak` to be
safe, the allocator must not free its underlying backing store. The
`Allocator` trait only guarantees that allocated memory remains valid
until the allocator is dropped.
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
`x clean` was failing when it encountered a special file like a fifo
because it thought it was a directory.
|
|
Remove `ItemKind::descr` method
Follow-up of rust-lang/rust#143234.
After this PR is merged, it will remain two `descr` methods:
* `hir::GenericArg::descr`
* `hir::AssocItemConstraintKind::descr`
For both these enums, I don't think there is the right equivalent in `hir::DefKind` so unless I missed something, we can't remove these two methods because we can't convert these enums into `hir::DefKind`.
r? `@oli-obk`
|
|
bootstrap: make comment more clear
Reading that at first made me think the code block ensures that the said artefacts are created
|
|
mir: Mark `Statement` and `BasicBlockData` as `#[non_exhaustive]`
Ensure they are always created using constructors.
r? oli-obk
|
|
Do not enable LLD by default in the dist profile
History of us building & shipping LLD for `dist` builds:
1) We used to unconditionally build & ship LLD in bootstrap
2) This was causing problems for people doing custom `dist` builds (https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)
3) https://github.com/rust-lang/rust/pull/126701 made shipping of LLD optional, but to preserve previous behavior, it forcefully enabled `rust.lld = true` in the `dist` profile by default, and overwrote the default to `false` on our CI for external LLVM builds.
- This also didn't match the documentation of `rust.lld` in `bootstrap.example.toml`, which I previously missed.
4) However, since the external LLVM opt-out was only implemented for our CI, and not for all `dist` users, this started causing issues for people `dist`ing with external LLVM (https://github.com/rust-lang/rust/issues/143076). The problem is that the default shouldn't be "true", but "LLD is enabled when LLVM isn't external", but this is not possible to do only in TOML.
So this PR reverses the behavior. LLD is not enabled by default in `dist` anymore. We switch our CI to *opt into* disting LLD, unless an external LLVM is used. External `dist` users can still opt into enabling LLD, but if they do so while also using external LLVM, they will now get a [hard error](https://github.com/rust-lang/rust/pull/143175).
r? `@jieyouxu`
try-job: `x86_64-mingw*`
try-job: dist-x86_64-linux
|
|
r=oli-obk
Port `#[rustc_object_lifetime_default]` to the new attribute parsing …
Ports rustc_object_lifetime_default to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@oli-obk`
cc `@jdonszelmann`
|
|
[COMPILETEST-UNTANGLE 2/N] Make some compiletest errors/warnings/help more visually obvious
This PR makes some compiletest errors/warnings/help more visually obvious. Note that this is only intended to help visually -- the error handling in compiletest is still a mess.
r? ghost
|
|
`tests/ui`: A New Order [20/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
|
|
`tests/ui`: A New Order [19/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
|
|
Improve testing and error messages for malformed attributes
This PR has been split into 5 commits for reviewability, I recommend reviewing them one-by-one.
This first commit introduces more tests, the other 4 commits fix 4 bugs discovered by the test.
r? `@oli-obk`
cc `@jdonszelmann`
Fixes https://github.com/rust-lang/rust/issues/143136
|
|
docs(fs): Touch up grammar on lock api
|
|
Describe Future invariants more precisely
|
|
Implement `Random` for tuple
Implement `Random` for tuples of arity 12 or less. Each element is expected to implement `Random`.
I think it's OK to implement this trait for the following types:
- Primitive integer types and `bool`
- Arrays and tuples of the above values
- ~~`NonZero<T>`~~, `Saturating<T>` and `Wrapping<T>`
The necessity of this trait is debated (<https://github.com/rust-lang/rust/issues/130703#issuecomment-2508889577>), but if we decide to keep it in the future when the `random` module is stabilized, I think it would be useful to have this trait implemented for tuples.
Tracking issue: #130703
r? `@joboet`
|
|
`ItemKind::descr`
|
|
`ItemKind::descr`
|
|
Start moving wf checking away from HIR
I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better.
I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks.
Especially https://github.com/rust-lang/rust/commit/b862d8828e375ab8c128a9d9e93bf98b77cb5928 is interesting here, because I think it improves spans in all cases
|
|
|
|
`rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end`
|
|
infrastructure
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
fixes issue 143203
|
|
|
|
Migrate `toggle_macro_delimiter` Assist to use `SyntaxEditor`
|
