| Age | Commit message (Collapse) | Author | Lines |
|---|
|
`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.
|
|
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.
|
|
|
|
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
|
|
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`
|
|
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>
|
|
|
|
Split exported_symbols for generic and non-generic symbols
This reduces metadata decoder overhead during the monomorphization collector.
|
|
|
|
Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attrib…
Ports `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@jdonszelmann`
|
|
Reading that at first made me think the code block ensures that the said artefacts are created
|
|
|
|
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
|
|
|
|
fix: Emit suggestion filename if primary diagnostic span is dummy
While working on using `annotate-snippets` as `rustc`'s emitter, I came across [`tests/ui/resolve/resolve-conflict-extern-crate-vs-extern-crate.stderr`](https://github.com/rust-lang/rust/blob/b03b3a7ec92682be2917540b679478d41c95a30c/tests/ui/resolve/resolve-conflict-extern-crate-vs-extern-crate.stderr), which lacked a filename for both the annotation and the suggestion, which seemed like a bug to me. After some investigation, I found that this is happening because the primary span is a dummy, so its filename doesn't get output, and its filename matches the one for the suggestion, so the suggestion's filename doesn't get output. To fix this issue, I made it so that the filename for a suggestion will get output if the primary span is a dummy.
|
|
r=compiler-errors
linkify CodeSuggestion in doc comments
|
|
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 .
|
|
Replace `ItemCtxt::report_placeholder_type_error` match with a call to `TyCtxt::def_descr`
Fixes rust-lang/rust#143128.
We could likely use `tcx.def_descr` in more places (and therefore remove more `descr` methods). If it's something that we want to do, I can send a follow-up.
r? `@oli-obk`
|
|
rustdoc default faviocon
rust-lang/rust#143154
default favicon now appears to be the new behavior, instead of no favicon.
|
|
r=workingjubilee
inherit `#[align]` from trait method prototypes
````@workingjubilee```` this seems straightforward enough. Now that we're planning to make `-Cmin-function-alignment` a target modifier, I don't think there are any cross-crate complications here?
````@Jules-Bertholet```` is this the behavior you had in mind? In particular the inheritance of the attribute of a default impl is maybe a bit unintuitive at first? (but I think it's ok if that behavior is explicitly documented).
r? ghost
|
|
Disable f16 on Aarch64 without neon for llvm < 20.1.1
This check was added unconditionally in c51b229140 ("Disable f16 on Aarch64 without `neon`") and reverted in 4a8d35709e ("Revert "Disable `f16` on Aarch64 without `neon`"") since it did not fail in Rust's build. However, it is still possible to hit this crash if using LLVM 19 built with assertions, so disable the type conditionally based on version here.
Note that for these builds, a similar patch is needed in the build script for `compiler-builtins` since it does not yet use `cfg(target_has_reliable_f16)` (hopefully to be resolved in the near future).
Report: https://github.com/rust-lang/rust/pull/139276#issuecomment-3014781652
Original LLVM issue: https://github.com/llvm/llvm-project/issues/129394
|
|
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.
|
|
|
|
Ensure they are always created using constructors.
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143019 (Ensure -V --verbose processes both codegen_backend and codegen-backend)
- rust-lang/rust#143140 (give Pointer::into_parts a more scary name and offer a safer alternative)
- rust-lang/rust#143175 (Make combining LLD with external LLVM config a hard error)
- rust-lang/rust#143180 (Use `tracing-forest` instead of `tracing-tree` for bootstrap tracing)
- rust-lang/rust#143223 (Improve macro stats printing)
- rust-lang/rust#143228 (Handle build scripts better in `-Zmacro-stats` output.)
- rust-lang/rust#143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary)
- rust-lang/rust#143246 (Subtree update of `rust-analyzer`)
- rust-lang/rust#143248 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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
|
|
Move this structure directly above the `parse_<expr>` functions that
return it to keep top-down flow.
This is a non-functional change.
|
