| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit cbe932801892da06688b53638622be1c8a1c8974.
|
|
This reverts commit a884a9e634b827781e77bddf4082f1196301d86f.
|
|
After removing `GenFuture`, I special-cased async generators to pretty-print as `impl Future<Output = X>` mainly to avoid too much diagnostics changes originally.
This now reverses that change so that async fn/blocks are pretty-printed as `[$movability `async` $something@$source-position]` in various diagnostics, and updates the tests that this touches.
|
|
Use the power of adding helper function to simplify code w/ `Mutability`
r? `@compiler-errors`
|
|
|
|
Add `ConstKind::Expr`
Starting to implement `ty::ConstKind::Abstract`, most of the match cases are stubbed out, some I was unsure what to add, others I didn't want to add until a more complete implementation was ready.
r? `@lcnr`
|
|
Rollup of 8 pull requests
Successful merges:
- #104716 (move 2 candidates into builtin candidate)
- #104760 (Clarify `SyntaxExtensionKind::LegacyDerive`.)
- #104797 (rustc_codegen_ssa: write `.dwp` in a streaming fashion)
- #104835 (Use infcx.partially_normalize_associated_types_in)
- #104853 (Fix typo in miri sysroot)
- #104879 (jsondoclint: Recognise Typedef as valid kind for Type::ResolvedPath)
- #104887 (rustbuild: Don't build doc::SharedAssets when building JSON docs.)
- #104896 (rustdoc: fix broken tooltip CSS)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
spastorino:use-partially_normalize_associated_types_in, r=lcnr
Use infcx.partially_normalize_associated_types_in
r? ``@lcnr``
|
|
move 2 candidates into builtin candidate
having separate candidates for these isn't too helpful i think
r? types
|
|
spastorino:santa-clauses-make-goals-early-christmas-🎄, r=oli-obk
Branch Clause from Predicate
r? `@oli-obk`
This is part of what's proposed in https://github.com/rust-lang/compiler-team/issues/531
|
|
|
|
Assert that we don't capture escaping bound vars in `Fn` trait selection
Fixes #104825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds the ability to directly expand a const to an expr without having to deal with intermediate
steps.
|
|
Initial pass at expr/abstract const/s
Address comments
Switch to using a list instead of &[ty::Const], rm `AbstractConst`
Remove try_unify_abstract_consts
Update comments
Add edits
Recurse more
More edits
Prevent equating associated consts
Move failing test to ui
Changes this test from incremental to ui, and mark it as failing and a known bug.
Does not cause the compiler to ICE, so should be ok.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=lcnr
with_query_mode -> new
r? ```@lcnr```
|
|
r=jackh726
Remove normalize_projection_type
r? ``@lcnr``
|
|
|
|
Avoid `GenFuture` shim when compiling async constructs
Previously, async constructs would be lowered to "normal" generators, with an additional `from_generator` / `GenFuture` shim in between to convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that async constructs will *directly* implement `Future` without the need to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation detail in stack traces and debuginfo, but it can in theory also help the optimizer as there is less abstractions to see through.
---
Given this demo code:
```rust
pub async fn a(arg: u32) -> Backtrace {
let bt = b().await;
let _arg = arg;
bt
}
pub async fn b() -> Backtrace {
Backtrace::force_capture()
}
```
I would get the following with the latest stable compiler (on Windows):
```
4: async_codegen::b::async_fn$0
at .\src\lib.rs:10
5: core::future::from_generator::impl$1::poll<enum2$<async_codegen::b::async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
6: async_codegen::a::async_fn$0
at .\src\lib.rs:4
7: core::future::from_generator::impl$1::poll<enum2$<async_codegen::a::async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
```
whereas now I get a much cleaner stack trace:
```
3: async_codegen::b::async_fn$0
at .\src\lib.rs:10
4: async_codegen::a::async_fn$0
at .\src\lib.rs:4
```
|
|
|
|
|
|
Previously, async constructs would be lowered to "normal" generators,
with an additional `from_generator` / `GenFuture` shim in between to
convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that
async constructs will *directly* implement `Future` without the need
to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation
detail in stack traces and debuginfo, but it can in theory also help
the optimizer as there is less abstractions to see through.
|
|
Make `deref_into_dyn_supertrait` lint the impl and not the usage
Proposed by ``@compiler-errors`` in https://github.com/rust-lang/rust/issues/89460#issuecomment-1320806785
r? ``@crlf0710``
|
|
Properly handle `Pin<&mut dyn* Trait>` receiver in codegen
This ensures we can actually await a `dyn* Future`, which seems important for async fn in dyn trait.
Also, disable `dyn*` trait upcasting. It's not exactly complete right now, and can cause strange ICEs for no reason -- nobody's using it either. I thought it was cute to implement when I did it, but I didn't think about how it interacts structurally with `CoerceUnsized` correctly.
Fixes #104794, presumably removing `dyn*` upcasting and its `CoerceUnsized` issues does the trick.
|
|
Reverts check done by #100757
As my `fix` caused more issues than it resolved it's better to revert it.
( #103274 #104322 https://github.com/rust-lang/rust/issues/104606)
r? `@compiler-errors`
Reopens #95134
|
|
|
|
Use `as_deref` in compiler (but only where it makes sense)
This simplifies some code :3
(there are some changes that are not exacly `as_deref`, but more like "clever `Option`/`Result` method use")
|
|
|
|
|
|
Use obligation ctxt instead of dyn TraitEngine
r? `@lcnr`
|
|
Fix hang in where-clause suggestion with `predicate_can_apply`
Using `predicate_may_hold` during error reporting causes an evaluation overflow, which (because we use `evaluate_obligation_no_overflow`) then causes the predicate to need to be re-evaluated locally, which results in a hang.
... but since the "add a where clause" suggestion is best-effort, just throw any overflow errors. No need for 100% accuracy.
r? `@lcnr` who has been thinking about overflows... Let me know if you want more context about this issue, and as always, feel free to reassign.
Fixes #104225
|
|
|
|
|
|
|
|
|
