| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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>
|
|
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`
|
|
[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>
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
|
|
re-balance CI jobs
|
|
./miri toolchain: no need to run 'cargo metadata'
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#143125 (Disable f16 on Aarch64 without neon for llvm < 20.1.1)
- rust-lang/rust#143156 (inherit `#[align]` from trait method prototypes)
- rust-lang/rust#143178 (rustdoc default faviocon)
- rust-lang/rust#143234 (Replace `ItemCtxt::report_placeholder_type_error` match with a call to `TyCtxt::def_descr`)
- rust-lang/rust#143245 (mbe: Add tests and restructure metavariable expressions)
- rust-lang/rust#143257 (Upgrade dependencies in run-make-support)
- rust-lang/rust#143263 (linkify CodeSuggestion in doc comments)
- rust-lang/rust#143264 (fix: Emit suggestion filename if primary diagnostic span is dummy)
Failed merges:
- rust-lang/rust#143251 (bootstrap: add build.tidy-extra-checks option)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
Upgrade dependencies in run-make-support
The main purpose of this is to upgrade `object` and `gimli`, which will allow us to drop outdated versions once backtrace also updates. The only semver breakage in `object`'s is in `elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld, which don't appear to be used here. `gimli` is similar, there is only minor breakage related to dyld.
These version upgrades were also done in the library.
`bstr`, `similar`, and `regex` are also upgraded to the latest minor version here to match what the lockfile already uses. The `regex` comment about `memchr` version hasn't been relevant to this lockfile since e95d15a11519 ("Pin memchr to 2.5.0 in the library rather than rustc_ast") and is no longer relevant in the library lockfile either.
Object Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
Gimli changelog: https://github.com/gimli-rs/gimli/blob/master/CHANGELOG.md#0320
|
|
r=petrochenkov
mbe: Add tests and restructure metavariable expressions
Add tests that show better diagnostics, and factor `concat` handling to a separate function. Each commit message has further details.
This performs the nonfunctional perparation for further changes such as https://github.com/rust-lang/rust/pull/142950 and https://github.com/rust-lang/rust/pull/142975 .
|
|
Introduce `ByteSymbol`
It's like `Symbol` but for byte strings. The interner is now used for both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"` you'll get a `Symbol` and a `ByteSymbol` with the same index and the characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate `ast::LitKind` in HIR. The latter change reduces peak memory by a non-trivial amount on literal-heavy benchmarks such as `deep-vector` and `tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some changes so that they can handle normal strings and byte strings.
|
|
The main purpose of this is to upgrade `object` and `gimli`, which will
allow us to drop outdated versions once backtrace also updates.
The only semver breakage in `object`'s is in `elf::R_RISCV_GNU_*` and
`pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld, which don't
appear to be used here. `gimli` is similar, there is only minor breakage
related to dyld.
These version upgrades were also done in the library.
`bstr`, `similar`, and `regex` are also upgraded to the latest minor
version here to match what the lockfile already uses. The `regex`
comment about `memchr` version hasn't been relevant to this lockfile
since e95d15a11519 ("Pin memchr to 2.5.0 in the library rather than
rustc_ast") and is no longer relevant in the library lockfile either.
Object Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
Gimli changelog: https://github.com/gimli-rs/gimli/blob/master/CHANGELOG.md#0320
|
|
Subtree update of `rust-analyzer`
r? ``@ghost``
|
|
[COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary
This is part of a patch series to untangle `compiletest` to hopefully nudge it towards being more maintainable.
This PR:
- Moves some early config checks (some warnings) to the compiletest library.
- Moves `src/main.rs` to `src/bin/main.rs` to make the separation (as in, compiletest's library component vs the tool binary component) more obvious.
r? ``@Kobzol`` (or reroll)
|
|
Make combining LLD with external LLVM config a hard error
Younger me made this only a warning in https://github.com/rust-lang/rust/pull/139853, because our post-dist tests were relying on this. But that was not a good idea, because there are a bunch of places in bootstrap that outright try to build LLD/copy LLD to sysroot when `lld_enabled` is true (rightfully so), which is causing issues (https://github.com/rust-lang/rust/issues/143076). Instead of piling more hacks, I'd like to just disallow this, and if we need to use a hack, do it only for our CI.
If this breaks the CI post-dist tests, I'll either add some special environment variable for it, or, as an alternative, make the error back into a warning, but also disable `lld_enabled` when this situation happens.
try-job: dist-x86_64-linux
Fixes: https://github.com/rust-lang/rust/pull/143175
|
|
give Pointer::into_parts a more scary name and offer a safer alternative
`into_parts` is a bit too innocent of a name for a somewhat subtle operation.
r? `@oli-obk`
|
|
|
|
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#142429 (`tests/ui`: A New Order [13/N])
- rust-lang/rust#142514 (Miri: handling of SNaN inputs in `f*::pow` operations)
- rust-lang/rust#143066 (Use let chains in the new solver)
- rust-lang/rust#143090 (Workaround for memory unsafety in third party DLLs)
- rust-lang/rust#143118 (`tests/ui`: A New Order [15/N])
- rust-lang/rust#143159 (Do not freshen `ReError`)
- rust-lang/rust#143168 (`tests/ui`: A New Order [16/N])
- rust-lang/rust#143176 (fix typos and improve clarity in documentation)
- rust-lang/rust#143187 (Add my work email to mailmap)
- rust-lang/rust#143190 (Use the `new` method for `BasicBlockData` and `Statement`)
- rust-lang/rust#143195 (`tests/ui`: A New Order [17/N])
- rust-lang/rust#143196 (Port #[link_section] to the new attribute parsing infrastructure)
- rust-lang/rust#143199 (Re-disable `tests/run-make/short-ice` on Windows MSVC again)
- rust-lang/rust#143219 (Show auto trait and blanket impls for `!`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
fix typos and improve clarity in documentation
```
Description:
This pull request corrects minor typos and improves wording for clarity across several documentation files, including:
- Correcting instrinsics → intrinsics
- Correcting preferrably → preferably
- Correcting Orginally → Originally
- Correcting resiliant → resilient
```
|
|
Miri: handling of SNaN inputs in `f*::pow` operations
fixes [miri/#4286](https://github.com/rust-lang/miri/issues/4286) and related to rust-lang/rust#138062 and [miri/#4208](https://github.com/rust-lang/miri/issues/4208#issue-2879058184).
For the following cases of the powf or powi operations, Miri returns either `1.0` or an arbitrary `NaN`:
- `powf(SNaN, 0.0)`
- `powf(1.0, SNaN)`
- `powi(SNaN, 0)`
Also added a macro in `miri/tests/pass/float.rs` which conveniently checks if both are indeed returned from such an operation.
Made these changes in the rust repo so I could test against stdlib, since these were impacted some time ago and were fixed in rust-lang/rust#138062. Tested with:
```fish
env MIRIFLAGS=-Zmiri-many-seeds ./x miri --no-fail-fast std core coretests -- f32 f64
```
This was successful. This does take a while, so I recommend using `--no-doc` and separate use of `f32` or `f64`
The pr is somewhat split up into 3 main commits, which implement the cases described above. The first commit also introduces the macro, and the last commit is just a global refactor of some things.
r? `@RalfJung`
|
|
`tests/ui`: A New Order [13/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ```@jieyouxu```
|
|
It's like `Symbol` but for byte strings. The interner is now used for
both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"`
you'll get a `Symbol` and a `ByteSymbol` with the same index and the
characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to
make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate
`ast::LitKind` in HIR. The latter change reduces peak memory by a
non-trivial amount on literal-heavy benchmarks such as `deep-vector` and
`tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some
changes so that they can handle normal strings and byte strings.
This change does slow down compilation of programs that use
`include_bytes!` on large files, because the contents of those files are
now interned (hashed). This makes `include_bytes!` more similar to
`include_str!`, though `include_bytes!` contents still aren't escaped,
and hashing is still much cheaper than escaping.
|
|
|
|
|
|
|
|
|
|
|
|
To make it obvious `compiletest`-the-tool has two components:
1. The core compiletest library, and
2. The tool binary, which will be executed by bootstrap.
|
