| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 7 pull requests
Successful merges:
- #124570 (Miscellaneous cleanups)
- #124772 (Refactor documentation for Apple targets)
- #125011 (Add opt-for-size core lib feature flag)
- #125218 (Migrate `run-make/no-intermediate-extras` to new `rmake.rs`)
- #125225 (Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS)
- #125266 (compiler: add simd_ctpop intrinsic)
- #125348 (Small fixes to `std::path::absolute` docs)
Failed merges:
- #125296 (Fix `unexpected_cfgs` lint on std)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiler: add simd_ctpop intrinsic
Fairly straightforward addition.
cc `@rust-lang/opsem` new (extremely boring) intrinsic
|
|
|
|
generics' attributes
|
|
|
|
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Split out `ty::AliasTerm` from `ty::AliasTy`
Splitting out `AliasTerm` (for use in project and normalizes goals) and `AliasTy` (for use in `ty::Alias`)
r? lcnr
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Uplift `TraitRef` into `rustc_type_ir`
Emotional rollercoaster
r? lcnr
|
|
|
|
Rename some `FulfillmentErrorCode`/`ObligationCauseCode` variants to be less redundant
1. Rename some `FulfillmentErrorCode` variants.
2. Always use `ObligationCauseCode::` to prefix a code, rather than using a glob import and naming them through `traits::`.
3. Rename some `ObligationCauseCode` variants -- I wasn't particularly thorough with thinking of a new names for these, so could workshop them if necessary.
4. Misc stuff from renaming.
r? lcnr
|
|
|
|
|
|
|
|
|
|
Make `Ty::builtin_deref` just return a `Ty`
Nowhere in the compiler are we using the mutability part of the `TyAndMut` that we used to return.
|
|
Rollup of 7 pull requests
Successful merges:
- #124551 (Add benchmarks for `impl Debug for str`)
- #124915 (`rustc_target` cleanups)
- #124918 (Eliminate some `FIXME(lcnr)` comments)
- #124927 (opt-dist: use xz2 instead of xz crate)
- #124936 (analyse visitor: build proof tree in probe)
- #124943 (always use `GenericArgsRef`)
- #124955 (Use fewer origins when creating type variables.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use fewer origins when creating type variables.
To reduce lots of repetitive boilerplate code. Details in the individual commit messages.
r? ``@lcnr``
|
|
Rename `Generics::params` to `Generics::own_params`
I hope this makes it slightly more obvious that `generics.own_params` is insufficient when considering nested items. I didn't actually audit any of the usages, for the record.
r? lcnr
|
|
|
|
|
|
`InferCtxt::next_{ty,const}_var*` all take an origin, but the
`param_def_id` is almost always `None`. This commit changes them to just
take a `Span` and build the origin within the method, and adds new
methods for the rare cases where `param_def_id` might not be `None`.
This avoids a lot of tedious origin building.
Specifically:
- next_ty_var{,_id_in_universe,_in_universe}: now take `Span` instead of
`TypeVariableOrigin`
- next_ty_var_with_origin: added
- next_const_var{,_in_universe}: takes Span instead of ConstVariableOrigin
- next_const_var_with_origin: added
- next_region_var, next_region_var_in_universe: these are unchanged,
still take RegionVariableOrigin
The API inconsistency (ty/const vs region) seems worth it for the
large conciseness improvements.
|
|
The starting point for this was identical comments on two different
fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
// FIXME: investigate making this a `Option<ErrorGuaranteed>`
recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed`
to `Recovered::Yes`. Then I ended up using `Recovered` instead of
`Option<ErrorGuaranteed>` for these two places and elsewhere, which
required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.
This makes things more consistent, because `Recovered` is used in more
places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible
to set `recovered` to `Recovered::Yes` without having emitted an error.
|
|
r=compiler-errors
Do not ICE on `AnonConst`s in `diagnostic_hir_wf_check`
Fixes #122989
Below is the snippet from #122989 that ICEs:
```rust
trait Traitor<const N: N<2> = 1, const N: N<2> = N> {
fn N(&N) -> N<2> {
M
}
}
trait N<const N: Traitor<2> = 12> {}
```
The `AnonConst` that triggers the ICE is the `2` in the param `const N: N<2> = 1`. The currently existing code in `diagnostic_hir_wf_check` deals only with `AnonConst`s that are default values of some param, but the `2` is not a default value. It is just an `AnonConst` HIR node inside a `TraitRef` HIR node corresponding to `N<2>`. Therefore the existing code cannot handle it and this PR ensures that it does.
|
|
Make `Bounds.clauses` private
Construct it through `Bounds::default()`, then consume the clauses via the method `Bounds::clauses()`.
This helps with effects desugaring where `clauses()` is not only the clauses within the `clauses` field.
|
|
|
|
Some hir cleanups
It seemed odd to not put `AnonConst` in the arena, compared with the other types that we did put into an arena. This way we can also give it a `Span` without growing a lot of other HIR data structures because of the extra field.
r? compiler
|
|
|
|
|
|
Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`
I don't think there is any need for the function, given that we can just access the `.types`, similarly to all other primitives?
|
|
|
|
|
|
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful
**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:
> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.
I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?
The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.
Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.
r? lcnr or compiler
|
|
Lazily normalize inside trait ref during orphan check & consider ty params in rigid alias types to be uncovered
Fixes #99554, fixes rust-lang/types-team#104.
Fixes #114061.
Supersedes #100555.
Tracking issue for the future compatibility lint: #124559.
r? lcnr
|
|
or inline such functions if useless.
|
|
to be uncovered
|
|
|
|
|
|
|
