| Age | Commit message (Collapse) | Author | Lines |
|
Only look for param in item's generics if it actually comes from generics
Record whether a `hir::GenericParam` comes from an item's generics, or from a `for<...>` binder. Then, only look for the param in `object_lifetime_default` if it actually comes from the item's generics.
Fixes #108177
|
|
Descriptive error when users try to combine RPITIT/AFIT with specialization
Previously we failed with some esoteric error like:
```
error[E0053]: method `foo` has an incompatible type for trait
--> $DIR/dont-project-to-specializable-projection.rs:14:35
|
LL | default async fn foo(_: T) -> &'static str {
| ^^^^^^^^^^^^ expected associated type, found future
|
note: type in trait
--> $DIR/dont-project-to-specializable-projection.rs:10:27
|
LL | async fn foo(_: T) -> &'static str;
| ^^^^^^^^^^^^
= note: expected signature `fn(_) -> impl Future<Output = &'static str>`
found signature `fn(_) -> impl Future<Output = &'static str>`
```
Now we error like:
```
error: async associated function in trait cannot be specialized
--> $DIR/dont-project-to-specializable-projection.rs:14:5
|
LL | default async fn foo(_: T) -> &'static str {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: specialization behaves in inconsistent and surprising ways with `#![feature(async_fn_in_trait)]`, and for now is disallowed
```
|
|
Remove the `capture_disjoint_fields` feature
As best I can tell, this was stabilized for Edition 2021 in #88126 but the feature was never removed.
|
|
Update books
## rust-lang/book
1 commits in d94e03a18a2590ed3f1c67b859cb11528d2a2d5c..21a2ed14f4480dab62438dcc1130291bebc65379
2023-02-13 19:45:29 UTC to 2023-02-13 19:45:29 UTC
- Removed "," typo on ch03-01 line 85 (rust-lang/book#3537)
## rust-lang/reference
1 commits in e5adb99c04817b7fbe08f4ffce5b36702667345f..a9afb04b47a84a6753e4dc657348c324c876102c
2023-02-14 14:57:15 UTC to 2023-02-14 14:57:15 UTC
- Document the `efiapi` ABI (rust-lang/reference#1309)
## rust-lang/rust-by-example
1 commits in efe23c4fe12e06351b8dc8c3d18312c761455109..af0998b7473839ca75563ba3d3e7fd0160bef235
2023-02-15 18:17:20 UTC to 2023-02-15 18:17:20 UTC
- Typographical mistake in tuples.md (rust-lang/rust-by-example#1685)
## rust-lang/rustc-dev-guide
30 commits in 41a96ab971cb45e2a184df20619ad1829765c990..b06dab84083390e0ee1e998f466545a8a1a76a9f
2023-02-26 22:30:52 UTC to 2023-02-14 05:16:01 UTC
- Fixed typing errors (rust-lang/rustc-dev-guide#1622)
- this remains true (rust-lang/rustc-dev-guide#1620)
- diagnostics: small fixes/improvements (rust-lang/rustc-dev-guide#1618)
- typo (rust-lang/rustc-dev-guide#1616)
- typo (rust-lang/rustc-dev-guide#1617)
- keep "grey area" lint summary green (rust-lang/rustc-dev-guide#1619)
- new solver: write canonicalization chapter (rust-lang/rustc-dev-guide#1595)
- bootstrap now creates a usable toolchain when building stage0 std (rust-lang/rustc-dev-guide#1615)
- llvm 13 is now not supported (rust-lang/rustc-dev-guide#1612)
- enable AND search (rust-lang/rustc-dev-guide#1607)
- Vetting deps datecheck (rust-lang/rustc-dev-guide#1614)
- mention Dev desktops, to help with LLVM builds (rust-lang/rustc-dev-guide#1613)
- fix and clarify llvm bugfix policy (rust-lang/rustc-dev-guide#1611)
- lower-case "Compiler" in headings, for consistency (and looks) (rust-lang/rustc-dev-guide#1605)
- Explain what the rest of the backend agnostic page is about (rust-lang/rustc-dev-guide#1609)
- Bump dependencies to fix CI (rust-lang/rustc-dev-guide#1610)
- rustc_codegen_ssa feels permanent enough not to need date-check (rust-lang/rustc-dev-guide#1606)
- make use of the `host` symlink in the build directory, to ease things (rust-lang/rustc-dev-guide#1608)
- have checkboxes only point to date-check lines in files (rust-lang/rustc-dev-guide#1603)
- remove stray text (rust-lang/rustc-dev-guide#1604)
- Typo (rust-lang/rustc-dev-guide#1601)
- Typo (rust-lang/rustc-dev-guide#1602)
- Add link to vscode settings in Rust repo (rust-lang/rustc-dev-guide#1591)
- avoid code duplication by including files in docs (rust-lang/rustc-dev-guide#1598)
- howto run the examples (rust-lang/rustc-dev-guide#1593)
- Add sample CodeLLDB launch.json (rust-lang/rustc-dev-guide#1482)
- typo (rust-lang/rustc-dev-guide#1600)
- use actual names (rust-lang/rustc-dev-guide#1594)
- Fix a typo (rust-lang/rustc-dev-guide#1597)
- Add Neovim configuration information (rust-lang/rustc-dev-guide#1545)
|
|
rustdoc: Show that repeated expression arrays can be made with constant values
The [rust reference](https://doc.rust-lang.org/reference/expressions/array-expr.html) currently says that repeated values for arrays can be constant or `Copy`
> repeat operand is [Copy](https://doc.rust-lang.org/reference/special-types-and-traits.html#copy) or that it must be a [path](https://doc.rust-lang.org/reference/expressions/path-expr.html) to a constant item
This updates the rust documentation on primitive arrays to reflect what the rust reference says (and also compiler suggestions if you do not use a `const` item)
|
|
Exit when there are unmatched delims to avoid noisy diagnostics
From https://github.com/rust-lang/rust/pull/104012#issuecomment-1311764832
r? ``@petrochenkov``
|
|
Inline `Poll` methods
With `opt-level="z"`, the `Poll::map*` methods are sometimes not inlined (see <https://godbolt.org/z/ca5ajKTEK>). This PR adds `#[inline]` to these methods. I have a project that can benefit from this change, but do we want to enable this behavior universally?
Fixes #101080.
|
|
|
|
|
|
|
|
|
|
|
|
r=GuillaumeGomez
rustdoc: reduce allocations when generating tooltips
An attempt to reduce the perf regression in
https://github.com/rust-lang/rust/pull/108052#issuecomment-1430631861
|
|
|
|
Stabilize cmpxchg16b_target_feature
Tracking issue for target features
+ #44839
stdarch issue
+ https://github.com/rust-lang/stdarch/issues/827
stdarch PR
+ https://github.com/rust-lang/stdarch/pull/1358
reference PR
+ https://github.com/rust-lang/reference/pull/1331
It's my first time contributing to rust-lang/rust. Please tell me if I missed something.
|
|
|
|
|
|
Stabilize `#![feature(target_feature_11)]`
## Stabilization report
### Summary
Allows for safe functions to be marked with `#[target_feature]` attributes.
Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits.
However, calling them from other `#[target_feature]` functions with a superset of features is safe.
```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}
fn foo() {
// Calling `avx2` here is unsafe, as we must ensure
// that AVX is available first.
unsafe {
avx2();
}
}
#[target_feature(enable = "avx2")]
fn bar() {
// Calling `avx2` here is safe.
avx2();
}
```
### Test cases
Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](https://github.com/rust-lang/rust/tree/b67ba9ba208ac918228a18321fc3a11a99b1c62b/src/test/ui/rfcs/rfc-2396-target_feature-11/).
### Edge cases
- https://github.com/rust-lang/rust/issues/73631
Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.
```rust
#[target_feature(enable = "avx2")]
fn qux() {
let my_closure = || avx2(); // this call to `avx2` is safe
let f: fn() = my_closure;
}
```
This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives.
### Documentation
- Reference: https://github.com/rust-lang/reference/pull/1181
---
cc tracking issue #69098
r? `@ghost`
|
|
Avoid invoking typeck from borrowck
This PR attempts to reduce direct dependencies between typeck and MIR-related queries. The goal is to have all the information transit either through THIR or through dedicated queries that avoid depending on the whole `TypeckResults`.
In a first commit, we store the type information that MIR building requires into THIR. This avoids edges between mir_built and typeck.
In the second and third commit, we wrap informations around closures (upvars, kind origin and user-provided signature) to avoid borrowck depending on typeck information.
There should be a single remaining borrowck -> typeck edge in the good path, due to inline consts.
|
|
Rollup of 8 pull requests
Successful merges:
- #104265 (Move IpAddr, SocketAddr and V4+V6 related types to `core`)
- #107110 ([stdio][windows] Use MBTWC and WCTMB)
- #108308 (Allow building serde and serde_derive in parallel)
- #108363 (Move the unused extern crate check back to the resolver.)
- #108519 (Bages for easy access links to Rust community)
- #108522 (Commit some new solver tests)
- #108523 (Avoid `&str` to `String` conversions)
- #108533 (diagnostics: avoid querying `associated_item` in the resolver)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=compiler-errors
diagnostics: avoid querying `associated_item` in the resolver
Fixes #108529
CC #108324
|
|
Avoid `&str` to `String` conversions
This patch removes some unnecessary `&str` to `String` conversions.
|
|
Commit some new solver tests
Lazy norm is hard.
`<?0 as Trait>::Assoc = ?0` ... probably should emit an alias-eq goal, but currently we don't do that. Right now it fails with a cyclical ty error.
Also committed a check-pass test that broken when I attempted to fix this (unsuccessfully).
r? types
|
|
Bages for easy access links to Rust community
r? `@Mark-Simulacrum`
|
|
Move the unused extern crate check back to the resolver.
It doesn't have anything to do in `rustc_hir_typeck`.
|
|
Allow building serde and serde_derive in parallel
This reduces build time of bootstrap by ~6s
|
|
[stdio][windows] Use MBTWC and WCTMB
`MultiByteToWideChar` and `WideCharToMultiByte` are extremely well optimized, and therefore should probably be used when we know we can (specifically in the Windows stdio stuff).
Fixes #107092
|
|
Move IpAddr, SocketAddr and V4+V6 related types to `core`
Implements RFC https://github.com/rust-lang/rfcs/pull/2832. The RFC has completed FCP with disposition merge, but is not yet merged.
Moves IP types to `core` as specified in the RFC.
The full list of moved types is: `IpAddr`, `Ipv4Addr`, `Ipv6Addr`, `SocketAddr`, `SocketAddrV4`, `SocketAddrV6`, `Ipv6MulticastScope` and `AddrParseError`.
Doing this move was one of the main driving arguments behind #78802.
|
|
|
|
Fixes #108529
|
|
|
|
Move THIR printing to rustc_mir_build.
https://github.com/rust-lang/rust/pull/107451 increased the compilation time of `rustc_middle` by 10% = 3s.
As https://github.com/rust-lang/rust/pull/107006 adds quite a lot of code to rustc_middle, I suspect it to be the cause.
This PR moves the THIR printing code to `rustc_mir_build`, where the query provider lives, in order to benefit from higher parallelism when compiling rustc.
|
|
|
|
MIR-Validate StorageLive.
`StorageLive` statements on a local which already has storage is banned by miri.
This check is easy enough, and can detect bugs in MIR opts.
|
|
This reduces build time of bootstrap by ~6s
|
|
Rollup of 9 pull requests
Successful merges:
- #108319 (Don't project specializable RPITIT projection)
- #108364 (Unify validity checks into a single query)
- #108463 (bootstrap: Update the output of the `check` descriptions)
- #108477 (Make `match` arm comma suggestion more clear)
- #108486 (Merge diagnostic_items duplicate diagnostics)
- #108494 (Clean up JS files code a bit)
- #108500 (update Miri)
- #108502 (Don't trigger error for ReError when other region is empty.)
- #108513 (Remove `@nagisa` from review rotation)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Remove @nagisa from review rotation
I have been reviewing PRs for a long while during weekends, however recently I’ve been having trouble commiting to that as well. Every weekend I’ve been spending working on a house.
I may return myself to the rotation in a couple of months. I may also just start ninja'ing up some PRs from the PR list whenever I find some time for reviews again, without putting myself back into the rotation, in acknowledgement that me being able to review every weekend or every second weekend is not a great experience for the contributors waiting on reviews from me.
|
|
Don't trigger error for ReError when other region is empty.
Fixes [#107988](https://github.com/rust-lang/rust/issues/107988)
|
|
update Miri
r? ``@ghost``
|
|
Clean up JS files code a bit
I mostly moved values closer to where they are used to make the code reading easier.
r? ```@notriddle```
|
|
Merge diagnostic_items duplicate diagnostics
To deduplicate how we diagnose duplication.
|
|
Make `match` arm comma suggestion more clear
Fixes #108472
|
|
bootstrap: Update the output of the `check` descriptions
This should bring the output from `x check` in line with the changes in #108171
|
|
Unify validity checks into a single query
Previously, there were two queries to check whether a type allows the 0x01 or zeroed bitpattern.
I am planning on adding a further initness to check in #100423, truly uninit for MaybeUninit, which would make this three queries. This seems overkill for such a small feature, so this PR unifies them into one.
I am not entirely happy with the naming and key type and open for improvements.
r? oli-obk
|
|
compiler-errors:dont-project-to-specializable-rpitits, r=lcnr
Don't project specializable RPITIT projection
This effective rejects specialization + RPITIT/AFIT (usages of `impl Trait` in traits) because the implementation is significantly complicated over making regular "default" trait method bodies work.
I have another PR that experimentally fixes all this, but the code may not be worth investing in.
|
|
|
|
|
|
I have been reviewing PRs for a long while during weekends, however
recently I’ve been having trouble commiting to that as well. Every
weekend I’ve been spending working on a house.
I may return myself to the rotation in a couple of months. I may also
just start ninja'ing up some PRs from the PR list whenever I find some
time for reviews again, without putting myself back into the rotation,
in acknowledgement that me being able to review every weekend or every
second weekend is not a great experience for the contributors waiting on
reviews from me.
|