| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows the use of `-Z track-diagnostics` to see the origin of
Clippy lints emission, as is already the case for lints coming from
rustc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add tracing_chrome under "tracing" feature
|
|
|
|
|
|
|
|
|
|
`iter_directives`} for self-consistency
|
|
|
|
compiletest has confusingly two terminology to refer to the same concept
-- "headers" and "directives". To make this more self-consistent and
less confusing, stick with "directives" only.
This commit **intentionally** tries to be limited to move-only (modulo
some key usage reference renames) to help git history.
|
|
Update stage0 to 1.89.0-beta.1
- Update version placeholders
- Update stage0 to 1.89.0-beta.1
- Update `STAGE0_MISSING_TARGETS`
- Update `cfg(bootstrap)`
r? `@Mark-Simulacrum`
try-job: dist-i586-gnu-i586-i686-musl
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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
|
|
[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
|
|
`ItemKind::descr`
|
|
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
|
|
Remove leaky synchronisation objects.
|
|
|
|
Split exported_symbols for generic and non-generic symbols
This reduces metadata decoder overhead during the monomorphization collector.
|
|
Prepare for rework done by the rest of RUST-142440.
Co-authored-by: Kivooeo <Kivooeo123@gmail.com>
|
