Rustup #10010
Merged
Rustup #10010
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… r=lcnr
Add `PolyExistentialPredicate` type alias
Wrapping `ExistentialPredicate`s in a binder is very common, and this alias already exists for the `PolyExistential{TraitRef,Projection}` types.
…lally allow trait resolution to prove false things during coherence
Co-authored-by: lcnr <[email protected]>
`MacArgs` is an enum with three variants: `Empty`, `Delimited`, and `Eq`. It's used in two ways: - For representing attribute macro arguments (e.g. in `AttrItem`), where all three variants are used. - For representing function-like macros (e.g. in `MacCall` and `MacroDef`), where only the `Delimited` variant is used. In other words, `MacArgs` is used in two quite different places due to them having partial overlap. I find this makes the code hard to read. It also leads to various unreachable code paths, and allows invalid values (such as accidentally using `MacArgs::Empty` in a `MacCall`). This commit splits `MacArgs` in two: - `DelimArgs` is a new struct just for the "delimited arguments" case. It is now used in `MacCall` and `MacroDef`. - `AttrArgs` is a renaming of the old `MacArgs` enum for the attribute macro case. Its `Delimited` variant now contains a `DelimArgs`. Various other related things are renamed as well. These changes make the code clearer, avoids several unreachable paths, and disallows the invalid values.
Rollup of 11 pull requests Successful merges: - #103396 (Pin::new_unchecked: discuss pinning closure captures) - #104416 (Fix using `include_bytes` in pattern position) - #104557 (Add a test case for async dyn* traits) - #104559 (Split `MacArgs` in two.) - #104597 (Probe + better error messsage for `need_migrate_deref_output_trait_object`) - #104656 (Move tests) - #104657 (Do not check transmute if has non region infer) - #104663 (rustdoc: factor out common button CSS) - #104666 (Migrate alias search result to CSS variables) - #104674 (Make negative_impl and negative_impl_exists take the right types) - #104692 (Update test's cfg-if dependency to 1.0) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Unreserve braced enum variants in value namespace
With this PR braced enum variants (`enum E { V { /*...*/ } }`) no longer take a slot in value namespace, so the special case mentioned in the note in https://github.com/rust-lang/rfcs/blob/master/text/1506-adt-kinds.md#braced-structs is removed.
Report - rust-lang/rust#103578 (comment).
Update Clippy r? `@Manishearth` Sorry for taking so long. There were so many blockers and so little time. This situation should be mitigated with #104007 in the future.
Allow opaque types in trait impl headers and rely on coherence to reject unsound cases r? ````@lcnr```` fixes #99840
…ler-errors Make `deref_into_dyn_supertrait` lint the impl and not the usage Proposed by ``@compiler-errors`` in rust-lang/rust#89460 (comment) r? ``@crlf0710``
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.
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
```
Make rustc_target usable outside of rustc I'm working on showing type size in rust-analyzer (rust-lang/rust-analyzer#13490) and I currently copied rustc code inside rust-analyzer, which works, but is bad. With this change, I would become able to use `rustc_target` and `rustc_index` directly in r-a, reducing the amount of copy needed. This PR contains some feature flag to put nightly features behind them to make crates buildable on the stable compiler + makes layout related types generic over index type + removes interning of nested layouts.
and fix the same typo in a bunch of other places
RefCell::get_mut: fix typo and fix the same typo in a bunch of other places
…istmas-🎄, r=oli-obk Branch Clause from Predicate r? `@oli-obk` This is part of what's proposed in rust-lang/compiler-team#531
Separate lifetime ident from lifetime resolution in HIR Drive-by: change how suggested generic args are computed. Fixes rust-lang/rust#103815 I recommend reviewing commit-by-commit.
Rename `ast::Lit` as `ast::MetaItemLit`. And some other literal cleanups. r? `@petrochenkov`
…torino Some initial normalization method changes 1. Rename `AtExt::normalize` to `QueryNormalizeExt::query_normalize` (using the `QueryNormalizer`) 2. Introduce `NormalizeExt::normalize` to replace `partially_normalize_associated_types_in` (using the `AssocTypeNormalizer`) 3. Rename `FnCtxt::normalize_associated_types_in` to `FnCtxt::normalize` 4. Remove some unused other normalization fns in `Inherited` and `FnCtxt` Also includes one drive-by where we're no longer creating a `FnCtxt` inside of `check_fn`, but passing it in. This means we don't need such weird `FnCtxt` construction logic. Stacked on top of #104835 for convenience. r? types
rustbot
added
the
S-waiting-on-review
|
@bors r+ |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? @ghost
changelog: none