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.
privacy: Fix more (potential) issues with effective visibilities
Continuation of https://github.com/rust-lang/rust/pull/103965.
See individual commits for more detailed description of the changes.
The shortcuts removed in 4eb63f618e and c7c7d16727 could actually be correct (or correct after some tweaks), but they used global reasoning like "we can skip this update because if the code compiles then some other update should do the same thing eventually".
I have some expertise in this area, but I still have doubt whether such global reasoning was correct or not, especially in presence of all possible exotic cases with imports.
After this PR all table changes should be "locally correct" after every update, even if it may be overcautious.
If similar optimizations are introduced again they will need detailed comments explaining why it's legal to do what they do and providing proofs.
Fixes https://github.com/rust-lang/rust/issues/104249.
Fixes https://github.com/rust-lang/rust/issues/104539.
Revert "Forbid inlining `thread_local!`'s `__getit` function on Windows"
Revert of #101368, fixes#104852.
I'd rather not do this since that's a soundness fix and this is hitting some compiler bug, but I don't really know an alternative.
r? `@ChrisDenton`
rustdoc: simplify `.search-results-title` CSS
By using `display: flex`, we still get the never-wrapping layout with `#crate-search-div` maxing out and truncating its text. The title itself winds up always filling its parent, but since `#crate-search` doesn't have `flex-grow` set, it won't fill available space.
make `error_reported` check for delayed bugs
Fixes#104768
`error_reported()` was only checking if there were errors emitted, not for `delay_bug`s which can also be a source of `ErrorGuaranteed`. I assume the same is true of `lint_err_count` but i dont know
resolve: Don't use constructor def ids in the map for field names
Also do some minor cleanup to insertion of those field names.
Addresses a FIXME left in https://github.com/rust-lang/rust/pull/103578.
Make rustc_target usable outside of rustc
I'm working on showing type size in rust-analyzer (https://github.com/rust-lang/rust-analyzer/pull/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.
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:🅱️:async_fn$0
at .\src\lib.rs:10
5: core::future::from_generator::impl$1::poll<enum2$<async_codegen:🅱️:async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
6: async_codegen:🅰️:async_fn$0
at .\src\lib.rs:4
7: core::future::from_generator::impl$1::poll<enum2$<async_codegen:🅰️: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:🅱️:async_fn$0
at .\src\lib.rs:10
4: async_codegen:🅰️: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.
Small accessibility improvements
From this [reddit post](https://www.reddit.com/r/rust/comments/z1gyz7/accessible_documentation/), I started to check a bit how to improve accessibility and how we could add test for it.
So these two fixes come from the use of the [pa11y tool](https://github.com/pa11y/pa11y). To make it work, I had to update its puppeteer version to the last one but otherwise it seems to be quite nice. I didn't fix all the errors it reported because they were about colors. To get the same result as mine, you can use this config:
```json
{
"ignore": [
"WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail",
"WCAG2AA.Principle3.Guideline3_2.3_2_2.H32.2"
]
}
```
I think trying to improve accessibility is something we should definitely aim for. I'll try to integrate a tool to enforce this check (very likely `pa11y`) directly into the CI.
cc ``@jsha``
r? ``@notriddle``
Add regression test for issue #99938
That issue was a dupe of #99852, and it got fixed since, but it's always better to have multiple regression tests rather than one.
closes#99938
Pass `InferCtxt` to `DropRangeVisitor` so we can resolve vars
The types that we encounter in the `TypeckResults` that we pass to the `DropRangeVisitor` are not yet fully resolved, since that only happens in writeback after type checking is complete.
Instead, pass down the whole `InferCtxt` so that we can resolve any inference vars that have been constrained since they were written into the results. This is similar to how the `MemCategorizationContext` in the `ExprUseVisitor` also needs to pass down both typeck results _and_ the inference context.
Fixes an ICE mentioned in this comment: https://github.com/rust-lang/rust/issues/104382#issuecomment-1324410781
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.
Throw error on failure in loading llvm-plugin
The following code silently ignores the error as the `LLVMRustSetLastError` only tracks one error at a time. At all other places where `LLVMRustSetLastError` is used the code immediately returns.
251831ece9/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp (L801-L804)
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")
Previously if the parent was not in the table, and there was nothing to inherit from, the child's private visibility was used, but that's not correct - the parent may have a larger visibility so we should set it to at least the parent's private visibility.
That parent's private visibility is also inserted into the table for caching, so it's not recalculated later if used again.
By using `display: flex`, we still get the never-wrapping layout with
`#crate-search-div` maxing out and truncating its text. The title itself
winds up always filling its parent, but since `#crate-search` doesn't have
`flex-grow` set, it won't fill available space.
Optimizations removed in the previous commit required this function to behave incorrectly, but now those optimizations are gone so we can fix the bug.
Fixes https://github.com/rust-lang/rust/issues/104249
First, they require eagerly calculating private visibility (current normal module), which is somewhat expensive.
Private visibilities are also lost once calculated, instead of being cached in the table.
Second, I cannot prove that the optimizations are correct.
Maybe they can be partially reinstated in the future in cases when it's cheap and provably correct to do them.
They will also probably be merged into `fn update` in that case.
Partially fixes https://github.com/rust-lang/rust/issues/104249
Fixes https://github.com/rust-lang/rust/issues/104539
