| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Move methods from `Map` to `TyCtxt`, part 5.
This eliminates all methods on `Map`. Actually removing `Map` will occur in a follow-up PR.
A follow-up to #137504.
r? `@Zalathar`
|
|
Various local trait item iteration cleanups
Adding a trait impl for `Foo` unconditionally affected all queries that are interested in a completely independent trait `Bar`. Perf has no effect on this. We probably don't have a good perf test for this tho.
r? `@compiler-errors`
I am unsure about https://github.com/rust-lang/rust/pull/139018/commits/9d05efb66f7b599eeacb5d2456f844fe4768e865 as it doesn't improve anything wrt incremental, because we still do all the checks for valid `Drop` impls, which subsequently will still invoke many queries and basically keep the depgraph the same.
I want to do
https://github.com/rust-lang/rust/blob/9549077a47099dc826039c051b528d1013740e6f/compiler/rustc_middle/src/ty/trait_def.rs#L141
but would leave that to a follow-up PR, this one changes enough things as it is
|
|
|
|
|
|
Check empty SIMD vector in inline asm
fixes [#134334](https://github.com/rust-lang/rust/issues/134334)
|
|
This eliminates all methods on `Map`. Actually removing `Map` will occur
in a follow-up PR.
|
|
|
|
|
|
Remove ScopeDepth
The scope depth was tracked, but never seemed to be used for anything.
Every single place that used `(Scope, ScopeDepth)`, matched it on `(p, _)`.
|
|
update outdated doc with new example
update the illegal definition example because we can compile `struct Ref<'a, T> { x: &'a T }` ([play](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=2eb2f8800d423c316b545c864623ae16))
|
|
|
|
The scope depth was tracked, but never actually used for anything.
|
|
It's an old (2017 or earlier) type that describes a `self` receiver.
It's only used in `rustc_hir_analysis` for two error messages, and much
of the complexity isn't used. I suspect it used to be used for more
things.
This commit removes it, and moves a greatly simplified version of the
`determine` method into `rustc_hir_analysis`, renamed as
`get_self_string`. The big comment on the method is removed because it
no longer seems relevant.
|
|
"Missing" patterns are possible in bare fn types (`fn f(u32)`) and
similar places. Currently these are represented in the AST with
`ast::PatKind::Ident` with no `by_ref`, no `mut`, an empty ident, and no
sub-pattern. This flows through to `{hir,thir}::PatKind::Binding` for
HIR and THIR.
This is a bit nasty. It's very non-obvious, and easy to forget to check
for the exceptional empty identifier case.
This commit adds a new variant, `PatKind::Missing`, to do it properly.
The process I followed:
- Add a `Missing` variant to `{ast,hir,thir}::PatKind`.
- Chang `parse_param_general` to produce `ast::PatKind::Missing`
instead of `ast::PatKind::Missing`.
- Look through `kw::Empty` occurrences to find functions where an
existing empty ident check needs replacing with a `PatKind::Missing`
check: `print_param`, `check_trait_item`, `is_named_param`.
- Add a `PatKind::Missing => unreachable!(),` arm to every exhaustive
match identified by the compiler.
- Find which arms are actually reachable by running the test suite,
changing them to something appropriate, usually by looking at what
would happen to a `PatKind::Ident`/`PatKind::Binding` with no ref, no
`mut`, an empty ident, and no subpattern.
Quite a few of the `unreachable!()` arms were never reached. This makes
sense because `PatKind::Missing` can't happen in every pattern, only
in places like bare fn tys and trait fn decls.
I also tried an alternative approach: modifying `ast::Param::pat` to
hold an `Option<P<Pat>>` instead of a `P<Pat>`, but that quickly turned
into a very large and painful change. Adding `PatKind::Missing` is much
easier.
|
|
It was never used.
|
|
|
|
There is no difference between the Patternand Borrow cases. Reduce it to
a simple struct.
|
|
They are unused.
|
|
|
|
Parameter patterns are lowered to an `Ident` by
`lower_fn_params_to_names`, which is used when lowering bare function
types, trait methods, and foreign functions. Currently, there are two
exceptional cases where the lowered param can become an empty `Ident`.
- If the incoming pattern is an empty `Ident`. This occurs if the
parameter is anonymous, e.g. in a bare function type.
- If the incoming pattern is neither an ident nor an underscore. Any
such parameter will have triggered a compile error (hence the
`span_delayed_bug`), but lowering still occurs.
This commit replaces these empty `Ident` results with `None`, which
eliminates a number of `kw::Empty` uses, and makes it impossible to fail
to check for these exceptional cases.
Note: the `FIXME` comment in `is_unwrap_or_empty_symbol` is removed. It
actually should have been removed in #138482, the precursor to this PR.
That PR changed the lowering of wild patterns to `_` symbols instead of
empty symbols, which made the mentioned underscore check load-bearing.
|
|
Move `hir::Item::ident` into `hir::ItemKind`.
`hir::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, Trait`, TraitAalis`.
- It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`, `Impl`.
- For `Use`, it is non-empty for `UseKind::Single` and empty for `UseKind::{Glob,ListStem}`.
All of this is quite non-obvious; the only documentation is a single comment saying "The name might be a dummy name in case of anonymous items". Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out.
This is step towards `kw::Empty` elimination (#137978).
r? `@fmease`
|
|
`hir::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
Trait`, TraitAalis`.
- It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`,
`Impl`.
- For `Use`, it is non-empty for `UseKind::Single` and empty for
`UseKind::{Glob,ListStem}`.
All of this is quite non-obvious; the only documentation is a single
comment saying "The name might be a dummy name in case of anonymous
items". Some sites that handle items check for an empty ident, some
don't. This is a very C-like way of doing things, but this is Rust, we
have sum types, we can do this properly and never forget to check for
the exceptional case and never YOLO possibly empty identifiers (or
possibly dummy spans) around and hope that things will work out.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- A similar transformation makes sense for `ast::Item`, but this is
already a big change. That can be done later.
- Lots of assertions are added to item lowering to ensure that
identifiers are empty/non-empty as expected. These will be removable
when `ast::Item` is done later.
- `ItemKind::Use` doesn't get an `Ident`, but `UseKind::Single` does.
- `lower_use_tree` is significantly simpler. No more confusing `&mut
Ident` to deal with.
- `ItemKind::ident` is a new method, it returns an `Option<Ident>`. It's
used with `unwrap` in a few places; sometimes it's hard to tell
exactly which item kinds might occur. None of these unwraps fail on
the test suite. It's conceivable that some might fail on alternative
input. We can deal with those if/when they happen.
- In `trait_path` the `find_map`/`if let` is replaced with a loop, and
things end up much clearer that way.
- `named_span` no longer checks for an empty name; instead the call site
now checks for a missing identifier if necessary.
- `maybe_inline_local` doesn't need the `glob` argument, it can be
computed in-function from the `renamed` argument.
- `arbitrary_source_item_ordering::check_mod` had a big `if` statement
that was just getting the ident from the item kinds that had one. It
could be mostly replaced by a single call to the new `ItemKind::ident`
method.
- `ItemKind` grows from 56 to 64 bytes, but `Item` stays the same size,
and that's what matters, because `ItemKind` only occurs within `Item`.
|
|
|
|
|
|
|
|
|
|
Add an opt-out in pretty printing for RTN rendering
Today, we render RPITIT types like `impl Sized { T::method(..) }` when RTN is enabled. This is very useful for diagnostics, since it's often not clear what the `impl Sized` type means by itself, and it makes it clear that that's an RPITIT that can be bounded using RTN syntax. See #115624.
However, since we don't distinguish types that are rendered for the purposes of printing messages vs suggestions, this representation leaks into suggestions and turns into code that can't be parsed. This PR adds a new `with_types_for_suggestion! {}` and `with_types_for_signature! {}` options to the pretty printing architecture to make it clear that we're rendering a type for code suggestions.
This can be applied later as we find that we need it.
|
|
|
|
Continuing the work from #137350.
Removes the unused methods: `expect_variant`, `expect_field`,
`expect_foreign_item`.
Every method gains a `hir_` prefix.
|
|
Add `#[define_opaques]` attribute and require it for all type-alias-impl-trait sites that register a hidden type
Instead of relying on the signature of items to decide whether they are constraining an opaque type, the opaque types that the item constrains must be explicitly listed.
A previous version of this PR used an actual attribute, but had to keep the resolved `DefId`s in a side table.
Now we just lower to fields in the AST that have no surface syntax, instead a builtin attribute macro fills in those fields where applicable.
Note that for convenience referencing opaque types in associated types from associated methods on the same impl will not require an attribute. If that causes problems `#[defines()]` can be used to overwrite the default of searching for opaques in the signature.
One wart of this design is that closures and static items do not have generics. So since I stored the opaques in the generics of functions, consts and methods, I would need to add a custom field to closures and statics to track this information. During a T-types discussion we decided to just not do this for now.
fixes #131298
|
|
|
|
Split up some of the tests bc tainting causes some errors to become
suppressed
|
|
|
|
Do not require that unsafe fields lack drop glue
Instead, we adopt the position that introducing an `unsafe` field itself carries a safety invariant: that if you assign an invariant to that field weaker than what the field's destructor requires, you must ensure that field is in a droppable state in your destructor.
See:
- https://github.com/rust-lang/rfcs/pull/3458#discussion_r1971676100
- https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/unsafe.20fields.20RFC/near/502113897
Tracking Issue: #132922
|
|
r=lcnr
Ensure that negative auto impls are always applicable
r? lcnr (or reassign if you dont want to review)
https://github.com/rust-lang/rust/issues/68318#issuecomment-2689265030
|
|
compiler-errors:no-implied-bounds-hack-unless-bevy, r=lcnr
Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack
Consolidates the implied bounds computation mode into a single function, which deeply normalizes, and if it's in **compat** mode (for bevy), it extracts outlives bounds from the infcx.
Previously, we were using the implied bounds compat mode in two cases:
1. During WF, if it detects `ParamSet`
2. EVERYWHERE ELSE (lol) -- e.g. borrowck, predicate entailment, etc.
While I think this is fine, and the net effect was just that we emitted fewer diagnostics, it makes me uncomfortable that all crates were using the supposed "compat" code.
Fixes #137767
|
|
bounds hack
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce `feature(generic_const_parameter_types)`
Allows to define const generic parameters whose type depends on other generic parameters, e.g. `Foo<const N: usize, const ARR: [u8; N]>;`
Wasn't going to implement for this for a while until we could implement it with `bad_inference.rs` resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc ``@workingjubilee`` )
|
|
|
|
Instead, we adopt the position that introducing an `unsafe` field
itself carries a safety invariant: that if you assign an invariant
to that field weaker than what the field's destructor requires,
you must ensure that field is in a droppable state in your
destructor.
See:
- https://github.com/rust-lang/rfcs/pull/3458#discussion_r1971676100
- https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/unsafe.20fields.20RFC/near/502113897
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #137370 (adjust_abi: make fallback logic for ABIs a bit easier to read)
- #137444 (Improve behavior of `IF_LET_RESCOPE` around temporaries and place expressions)
- #137464 (Fix invalid suggestion from type error for derive macro)
- #137539 ( Add rustdoc-gui regression test for #137082 )
- #137576 (Don't doc-comment BTreeMap<K, SetValZST, A>)
- #137595 (remove `simd_fpow` and `simd_fpowi`)
- #137600 (type_ir: remove redundant part of comment)
- #137602 (feature: fix typo in attribute description)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
remove `simd_fpow` and `simd_fpowi`
Discussed in https://github.com/rust-lang/rust/issues/137555
These functions are not exposed from `std::intrinsics::simd`, and not used anywhere outside of the compiler. They also don't lower to particularly good code at least on the major ISAs (I checked x86_64, aarch64, s390x, powerpc), where the vector is just spilled to the stack and scalar functions are used for the actual logic.
r? `@RalfJung`
|
|
|
