| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Simplify `ImplSource` candidates a bit
Reduce the number of impl source candidates, which will hopefully make our life easier when trying to adapt things like `SelectionContext::select` and `codegen_select_candidate` for the new solver.
r? `@lcnr` but feel free to reassign
|
|
|
|
|
|
|
|
|
|
|
|
Publish docs as github artifacts during CI
Discussed here: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Building.20docs.20for.20PR.20CI
The goal is to make docs available for download after CI runs on PRs, for easy review of API changes.
Notes:
- Currently this only captures library documentation (`core`, `alloc`, `std`, `test`, `proc_macro`)
- You can't see artifacts until the entire workflow run has completed https://github.com/actions/upload-artifact/issues/53
- There is currently a generic file name `ci-artifacts`. No way to customize this based on contained files unfortunately https://github.com/actions/upload-artifact/issues/349
You can find the results at the bottom of the CI "summary" page:
<img width="379" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/d3748e59-242c-40f8-9f54-82177b9b481b">
|
|
Add `AliasKind::Weak` for type aliases.
`type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a
```rust
trait Identity {
type Identity;
}
impl<T: Debug> Identity for T {
type Identity = T;
}
<NotDebug as Identity>::Identity
```
type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer.
Similarly:
* a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes
* rustdoc expands the type alias, even though often times users use them for documentation purposes
* diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about.
For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident.
To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition.
Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds.
As a side effect, easily allows fixing https://github.com/rust-lang/rust/issues/108617, which I did.
fixes https://github.com/rust-lang/rust/issues/108617
|
|
Rollup of 7 pull requests
Successful merges:
- #111074 (Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`)
- #112226 (std: available_parallelism using native netbsd api first)
- #112474 (Support 128-bit enum variant in debuginfo codegen)
- #112662 (`#[lang_item]` for `core::ptr::Unique`)
- #112665 (Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`)
- #112684 (Disable alignment checks on i686-pc-windows-msvc)
- #112706 (Add `SyntaxContext::is_root`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `SyntaxContext::is_root`
Makes the code a tad nicer.
|
|
Disable alignment checks on i686-pc-windows-msvc
r? `@wesleywiser` Because you were in the Zulip discussion of this: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202023-06-15
cc #112480
|
|
Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`
We just use an if-let to match on an optional clause at all the places where we transition from `Predicate` -> `Clause`, but I assume that when things like item-bounds and param-env start to only store `Clause`s then those can just be trivially dropped.
r? ``@lcnr``
|
|
`#[lang_item]` for `core::ptr::Unique`
Tree Borrows is about to introduce experimental special handling of `core::ptr::Unique` in Miri to give it a semantics.
As of now there does not seem to be a clean way (i.e. other than `&format!("{adt:?}") == "std::ptr::Unique"`) to check if an `AdtDef` represents a `Unique`.
r? `@RalfJung`
Draft: making a lang item
|
|
Support 128-bit enum variant in debuginfo codegen
fixes #111600
|
|
std: available_parallelism using native netbsd api first
before falling back to existing code paths like FreeBSD does.
|
|
r=Amanieu
Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`
TL;DR:
```diff,rust
-pub struct BufReader<R> { /* ... */ }
+pub struct BufReader<R: ?Sized> { /* ... */ }
-pub struct BufWriter<W: Write> { /* ... */ }
+pub struct BufWriter<W: ?Sized + Write> { /* ... */ }
-pub struct LineWriter<W: Write> { /* ... */ }
+pub struct LineWriter<W: ?Sized + Write> { /* ... */ }
```
This allows using `&mut BufReader<dyn Read>`, for example.
**This is an insta-stable change**.
|
|
|
|
Only use it when the type alias contains an opaque type.
Also does wf-checking on such type aliases.
|
|
Ignore the always part of #[inline(always)] in MIR inlining
`#[inline(always)]` is used in two cases: for functions that are so trivial it is always profitable to inline them, but also for functions which LLVM thinks are a bad inlining candidate, but which actually turn out to be profitable to inline. That second justification doesn't apply to the MIR inliner, so ignoring our cost estimation for these functions is not necessarily the right right thing to do.
This is basically a wash on non-check runs and a perf benefit in check runs. There are some notable regressions, and I think we might be able to claw those back by turning `#[inline(always)]` into a stronger hint. But I think this PR stands decently on its own as a tidy simplification.
|
|
|
|
|
|
rustdoc: Add search result item types after their name
Here what it looks like:
The idea is to improve accessibility by providing this information directly in the text and not only in the text color. Currently we already use it for doc aliases and for primitive types, so I extended it to all types.
r? `@notriddle`
|
|
comment tweaks
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #112163 (fix: inline `predicate_may_hold_fatal` and remove expect call in it)
- #112399 (Instantiate closure synthetic substs in root universe)
- #112443 (Opportunistically resolve regions in new solver)
- #112535 (reorder attributes to make miri-test-libstd work again)
- #112579 (Fix building libstd documentation on FreeBSD.)
- #112639 (Fix `dead_code_cgu` computation)
- #112642 (Handle interpolated literal errors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add tests for panicky drop in thread_local destructor
Adds a test for https://github.com/rust-lang/rust/issues/112285
|
|
|
|
|
|
Handle interpolated literal errors
Not sure why it was doing a whole dance to re-match on the token kind when it seems like `Lit::from_token` does the right thing for both macro-arg and regular literals. Nothing seems to have regressed diagnostics-wise from the change, though.
Fixes #112622
r? ``@nnethercote``
|
|
Fix `dead_code_cgu` computation
This PR fixes a bug in `dead_code_cgu` computation, and also does some refactoring.
r? ```@wesleywiser```
|
|
Fix building libstd documentation on FreeBSD.
It fixes the following error:
```
error[E0412]: cannot find type `sockcred2` in module `libc`
--> library/std/src/os/unix/net/ancillary.rs:211:29
|
211 | pub struct SocketCred(libc::sockcred2);
| ^^^^^^^^^ not found in `libc`
```
|
|
reorder attributes to make miri-test-libstd work again
Fixes fallout from https://github.com/rust-lang/rust/pull/110141
|
|
compiler-errors:next-solver-opportunistically-resolve-regions, r=lcnr
Opportunistically resolve regions in new solver
Use `opportunistic_resolve_var` during canonicalization to collapse some regions.
We have to start using `CanonicalVarValues::is_identity_modulo_regions`. We also have to modify that function to consider responses like `['static, ^0, '^1, ^2]` to be an "identity" response, since because we opportunistically resolve regions, there's no longer a 1:1 mapping between canonical var values and bound var indices in the response...
There's one nasty side-effect -- one test (`tests/ui/dyn-star/param-env-infer.rs`) starts to ICE because the certainty goes from `Yes` to `Maybe(Overflow)`... Not exactly sure why, though? Putting this up for discussion/investigation.
r? ```@lcnr```
|
|
Instantiate closure synthetic substs in root universe
In the UI test example, we end up generalizing an associated type (something like `<Map<Option<i32>, [closure upvars=?0]> as IntoIterator>::Item` generalizes into `<Map<Option<i32>, [closure upvars=?1]> as IntoIterator>::Item`) then assigning it to itself, emitting an alias-relate goal. This trivially holds via one of the normalizes-to candidates, instead of relating substs, so when closure analysis eventually sets `?0` to the actual upvars, `?1` never gets constrained. This ends up being reported as an ambiguity error during writeback.
Instead, we can take advantage of the fact that we *know* the closure substs live in the root universe. This will prevent them being generalized, since they always can be named, and the alias-relate above never gets emitted at all.
We can probably do this to a handful of other `next_ty_var` calls in typeck for variables that are clearly associated with the body of the program, but I wanted to limit this for now. Eventually, if we end up representing universes more faithfully like a tree or whatever, we can remove this and turn it back to just a call to `next_ty_var`.
Note: This is incredibly order-dependent -- we need to be assigning a type variable that was created *before* the closure substs, and we also need to actually have an unnormalized type at the time of the assignment. This currently seems easiest to trigger during call argument analysis just due to the fact that we instantiate the call's substs, normalize, THEN check args.
r? ```@lcnr```
|
|
fix: inline `predicate_may_hold_fatal` and remove expect call in it
- Fixes #105231
- Discussion: https://github.com/rust-lang/rust/pull/111985#discussion_r1208888821
r? ``@compiler-errors``
|
|
Use the relative sysroot path in the linker command line to specify sysroot rlibs
This addresses https://github.com/rust-lang/rust/issues/112586
|
|
Rustup
|
|
|
|
|
|
Add an `ensure_sufficient_stack` to `LateContextAndPass::visit_expr`
This is [apparently](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.60-alt.60-only.20failures.3F/near/365396801) where it's busting stack in #112238, and the comments for `ensure_sufficient_stack` say that
> E.g. almost any call to visit_expr or equivalent can benefit from this.
So this seems like a reasonable change.
Hopefully it'll keep this from happening in other places too -- https://github.com/rust-lang/rust/pull/111818#issuecomment-1585023914 hit something similar when updating a lint (bors failure is https://github.com/rust-lang-ci/rust/actions/runs/5199591324/jobs/9377196369), so with any luck this will keep small permutations of things from tripping over the limit.
|
|
|
|
Remove comments from mir-opt MIR dumps
See https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Line.20numbers.20in.20mir-opt.20tests/near/363849874
In https://github.com/rust-lang/rust/pull/99780 there is mention that "there has been a zulip conversation about disabling line numbers with mixed opinions" which to me means that some people opposed this. I can't find the referenced conversation so... here we go.
The current situation is quite chaotic. It's not hard to find MIR diffs which contain
* Absolute line numbers
* Relative line numbers
* Substituted line numbers (LL)
For example: https://github.com/rust-lang/rust/blob/408bbd040613f6776e0a7d05d582c81f4ddc189a/tests/mir-opt/inline/inline_shims.drop.Inline.diff#L10-L17
And sometimes adding a comment at the top of a mir-opt test generates a diff in the test because a line number changed: https://github.com/rust-lang/rust/pull/98112/files#diff-b8cf4bcce95078e6a3faf075e9abf6864872fb28a64d95c04f04513b9e3bbd81
And irrelevant changes to the standard library can generate diffs in mir-opt tests: https://github.com/rust-lang/rust/pull/110694/files#diff-bf96b0e7c67b8b272814536888fd9428c314991e155beae1f0a2a67f0ac47b2c
https://github.com/rust-lang/rust/commit/769886cc35ce08b76839f4cf72b8af1161c432e1
I think we should, specifically in mir-opt tests, completely remove the comments, or insert placeholders for all line and column numbers.
|
|
Rollup of 8 pull requests
Successful merges:
- #112403 (Prevent `.eh_frame` from being emitted for `-C panic=abort`)
- #112517 (`suspicious_double_ref_op`: don't lint on `.borrow()`)
- #112529 (Extend `unused_must_use` to cover block exprs)
- #112614 (tweak suggestion for argument-position `impl ?Sized`)
- #112654 (normalize closure output in equate_inputs_and_outputs)
- #112660 (Migrate GUI colors test to original CSS color format)
- #112664 (Add support for test tmpdir to fuchsia test runner)
- #112669 (Fix comment for ptr alignment checks in codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
|
