| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing
changes made to c6662879b27f5161e95f39395e3c9513a7b97028.
|
|
r=nnethercote
Fix dyn -> param suggestion in struct ICEs
Makes the logic from #138042 a bit less ICEy and more clean. Also fixes an incorrect suggestion when the struct already has generics. I'll point out the major changes and observations in the code.
Fixes #138229
Fixes #138211
r? nnethercote since you reviewed the original pr, or re-roll if you don't want to review this
|
|
|
|
Use workspace lints for crates in `compiler/`
This is nicer and hopefully less error prone than specifying lints via bootstrap.
r? ``@jieyouxu``
|
|
|
|
|
|
Delay bug for negative auto trait rather than ICEing
Fixes #138149
r? oli-obk
|
|
(Except for `rustc_codegen_cranelift`.)
It's no longer necessary now that `unreachable_pub` is in the workspace
lints.
|
|
By naming them in `[workspace.lints.rust]` in the top-level
`Cargo.toml`, and then making all `compiler/` crates inherit them with
`[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`,
because they're a bit different.)
The advantages of this over the current approach:
- It uses a standard Cargo feature, rather than special handling in
bootstrap. So, easier to understand, and less likely to get
accidentally broken in the future.
- It works for proc macro crates.
It's a shame it doesn't work for rustc-specific lints, as the comments
explain.
|
|
Suggest struct or union to add generic that impls trait
Fixes #135759
cc ```@tdittr```
|
|
|
|
It's clearer than using `kw::Empty` to mean `None`.
|
|
This is temporarily needed for `x doc compiler` to work. They can be
removed once the `Nonterminal` is removed (#124141).
|
|
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
|
|
Try to point of macro expansion from resolver and method errors if it involves macro var
In the case that a macro caller passes an identifier into a macro generating a path or method expression, point out that identifier in the context of the *macro* so it's a bit more clear how the macro is involved in causing the error.
r? ``````````@estebank`````````` or reassign
|
|
|
|
|
|
|
|
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
|
|
Check signature WF when lowering MIR body
Alternative to #137233.
https://github.com/rust-lang/rust/pull/137233#issuecomment-2667879143
Fixes https://github.com/rust-lang/rust/issues/137186
We do this check in `mir_drops_elaborated_and_const_checked` and not during `mir_promoted` because that may result in borrowck cycles if WF requires looking into an opaque hidden type. This causes some TAIT tests to fail unnecessarily.
r? lcnr
try-job: test-various
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
r=BoxyUwU
Allow struct field default values to reference struct's generics
Right now, the default field value feature (https://github.com/rust-lang/rust/issues/132162) lowers anon consts whose types may reference ADT params that the const doesn't inherit.
This PR fixes this, so that these defaults can reference ADTs' generics, and sets the `generics_of` parenting up correctly.
There doesn't seem to be a good reason not to support this, since the anon const has a well-defined type from the field, and the anon const doesn't interact with the type system like generic parameter defaults do.
r? `````@boxyuwu````` or reassign
I could also make this into an error if this seems problematic (https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:default-field-value-implicit-param?expand=1)...... but I'd rather make this work and register an open question on the tracking issue about validating that this is well-vetted.
Fixes #137896
|
|
bounds hack
|
|
|
|
|
|
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update `const_conditions` and `explicit_implied_const_bounds` docs
Move documentation to query definitions, and add docs to `explicit_implied_const_bounds`.
r? project-const-traits
|
|
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`` )
|
|
Move documentation to query definitions, and add docs to
`explicit_implied_const_bounds`.
|
|
Handle asm const similar to inline const
Previously, asm consts are handled similar to anon consts rather than inline consts. Anon consts are not good at dealing with lifetimes, because `type_of` has lifetimes erased already. Inline consts can deal with lifetimes because they live in an outer typeck context. And since `global_asm!` lacks an outer typeck context, we have implemented asm consts with anon consts while they're in fact more similar to inline consts.
This was changed in #137180, and this means that handling asm consts as inline consts are possible. While as `@compiler-errors` pointed out, `const` currently can't be used with any types with lifetime, this is about to change if #128464 is implemented. This PR is a preparatory PR for that feature.
As an unintentional side effect, fix #117877.
cc `@Amanieu`
r? `@compiler-errors`
|
|
|
|
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
|
|
|
|
Avoid collecting associated types for undefined trait
Fixes #137508
Fixes #137554
|
|
hir_analysis: skip self type of host effect preds in variances_of
Discovered as part of an implementation of rust-lang/rfcs#3729 - w/out this then when introducing const trait bounds: many more interesting tests change with different output, missing errors, new errors, etc related to this but they all depend on feature flags and are much more complex than this test.
r? ``@oli-obk``
|
|
remove few unused args
|
|
rename ui tests
check if res is trait def
fix typo
regression test for #137554
|
|
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`
|
|
|
|
|
