| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add a test for #104260
Fixes #104260
|
|
|
|
|
|
|
|
labels are reordered within the file in which they are reported, which can mess up the stack trace
|
|
|
|
|
|
r=cjgillot
Point at args in associated const fn pointers
Tiny follow-up to #105201, not so sure it's worth it but :shrug:
The UI test example is a bit more compelling when it's `GlUniformScalar::FACTORY`
r? `@cjgillot`
|
|
Add -Z maximal-hir-to-mir-coverage flag
This PR adds a new unstable flag `-Z maximal-hir-to-mir-coverage` that changes the behavior of `maybe_lint_level_root_bounded`, pursuant to [a discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Mapping.20MIR.20to.20HIR). When enabled, this function will not search upwards for a lint root, but rather immediately return the provided HIR node ID. This change increases the granularity of the mapping between MIR locations and HIR nodes inside the `SourceScopeLocalData` data structures. This increase in granularity is useful for rustc consumers like [Flowistry](https://github.com/willcrichton/flowistry) that rely on getting source-mapping information about the MIR CFG that is as precise as possible.
A test `maximal_mir_to_hir_coverage.rs` has been added to verify that this flag does not break anything.
r? `@cjgillot`
cc `@gavinleroy`
|
|
Replace usage of `ResumeTy` in async lowering with `Context`
Replaces using `ResumeTy` / `get_context` in favor of using `&'static mut Context<'_>`.
Usage of the `'static` lifetime here is technically "cheating", and replaces the raw pointer in `ResumeTy` and the `get_context` fn that pulls the correct lifetimes out of thin air.
fixes https://github.com/rust-lang/rust/issues/104828 and https://github.com/rust-lang/rust/pull/104321#issuecomment-1336363077
r? `@oli-obk`
|
|
Suggest removing struct field from destructive binding only in shorthand scenario
Fixes #105028
|
|
Fix `emit_unused_delims_expr` ICE
Fixes #104897
This is also related to #104433.
|
|
As suggested in #93516.
|
|
Avoid ICE by accounting for missing type
Fix #105330
|
|
support `ConstKind::Expr` in `is_const_evaluatable` and `WfPredicates::compute`
Fixes #105205
Currently we haven't implemented a way to evaluate `ConstKind::Expr(Expr::Binop(Add, 1, 2))` so I just left that with a `FIXME` and a `delay_span_bug` since I have no idea how to do that and it would make this a much larger (and more complicated) PR :P
|
|
Make `get_impl_future_output_ty` work with AFIT
Fixes #105304
|
|
Be more careful about unresolved exprs in suggestion
Fixes #105288
|
|
Synthesize substitutions for bad auto traits in dyn types
Auto traits are stored as just `DefId`s inside a `dyn Trait`'s existential predicates list. This is usually fine, since auto traits are forbidden to have generics -- but this becomes a problem for an ill-formed auto trait.
But since this will always result in an error, just synthesize some dummy (error) substitutions which are used at least to keep trait selection code happy about the number of substs in a trait ref.
Fixes #104808
|
|
Recurse into nested impl-trait when computing variance.
Fixes https://github.com/rust-lang/rust/issues/105251
|
|
propagate the error from parsing enum variant to the parser and emit out
While parsing enum variant, the error message always disappear
Because the error message that emit out is from main error of parser
The information of enum variant disappears while parsing enum variant with error
We only check the syntax of expecting token, i.e, in case https://github.com/rust-lang/rust/issues/103869
It will error it without telling the message that this error is from pasring enum variant.
Propagate the sub-error from parsing enum variant to the main error of parser by chaining it with map_err
Check the sub-error before emitting the main error of parser and attach it.
Fix https://github.com/rust-lang/rust/issues/103869
|
|
On E0195 point at where clause lifetime bounds
Fix #104733
|
|
Replaces using `ResumeTy` / `get_context` in favor of using `&'static mut Context<'_>`.
Usage of the `'static` lifetime here is technically "cheating", and replaces
the raw pointer in `ResumeTy` and the `get_context` fn that pulls the
correct lifetimes out of thin air.
|
|
|
|
|
|
Fix #104733
|
|
Fix #105330
|
|
|
|
Tweak "the following other types implement trait"
When *any* of the suggested impls is an exact match, *only* show the exact matches. This is particularly relevant for integer types.
r? `@compiler-errors`
|
|
r=jackh726
Point at GAT `where` clause when an obligation is unsatisfied
Slightly helps with #105306
|
|
Normalize inherent associated types after substitution
Fixes #105314.
r? ````@cjgillot```` (#105224)
````@rustbot```` label F-inherent_associated_types
|
|
Fix dupe word typos
|
|
|
|
attribute.
Compiler MCP:
https://github.com/rust-lang/compiler-team/issues/565
|
|
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
|
|
When *any* of the suggested impls is an exact match, *only* show the
exact matches. This is particularly relevant for integer types.
fix fmt
|
|
Skip recording resolution for duplicated generic params.
Turns out the fix was simpler than I thought.
Fixes https://github.com/rust-lang/rust/issues/104312
|
|
suggest parenthesis around ExprWithBlock BinOp ExprWithBlock
fix https://github.com/rust-lang/rust/issues/105179
fix https://github.com/rust-lang/rust/issues/102171
|
|
Use proper HirId for async track_caller attribute check
Fix #105134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoid some `InferCtxt::build` calls
Either because we're inside of an `InferCtxt` already, or because we're not in a place where we'd ever see inference vars.
r? types
|
|
|
|
Make sure async constructs do not `impl Generator`
Async lowering turns async functions and blocks into generators internally.
Though these special kinds of generators should not `impl Generator` themselves.
The other way around, normal generators should not `impl Future`.
This was discovered in https://github.com/rust-lang/rust/pull/105082#issuecomment-1332210907 and is a regression from https://github.com/rust-lang/rust/pull/104321.
r? `@compiler-errors`
|
|
rustc_codegen_ssa: Fix for codegen_get_discr
When doing the optimized implementation of getting the discriminant, the arithmetic needs to be done in the tag type so wrapping behavior works correctly.
Fixes #104519
|
