| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix #108495, postfix decrement and prefix decrement has no warning
Fixes #108495
|
|
|
|
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.
|
|
r=compiler-errors
diagnostics: avoid querying `associated_item` in the resolver
Fixes #108529
CC #108324
|
|
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
|
|
Move the unused extern crate check back to the resolver.
It doesn't have anything to do in `rustc_hir_typeck`.
|
|
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
|
|
|
|
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.
|
|
|
|
Don't trigger error for ReError when other region is empty.
Fixes [#107988](https://github.com/rust-lang/rust/issues/107988)
|
|
Merge diagnostic_items duplicate diagnostics
To deduplicate how we diagnose duplication.
|
|
Make `match` arm comma suggestion more clear
Fixes #108472
|
|
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.
|
|
|
|
|
|
|
|
hir-analysis: make a helpful note
|
|
Treat `str` as containing `[u8]` for auto trait purposes
Wanted to gauge ``@rust-lang/lang`` and ``@rust-lang/types`` teams' thoughts on treating `str` as "containing" a `[u8]` slice for auto-trait purposes.
``@dtolnay`` brought this up in https://github.com/rust-lang/rust/issues/13231#issuecomment-1399386472 as a blocker for future `str` type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that `str` type librarification (#107939), but this probably should be considered in the mean time regardless of that PR.
r? types for the impl, though this definitely needs an FCP.
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #107062 (Do some cleanup of doc/index.md)
- #107890 (Lint against `Iterator::map` receiving a callable that returns `()`)
- #108431 (Add regression test for #107918)
- #108432 (test: drop unused deps)
- #108436 (make "proc macro panicked" translatable)
- #108444 (docs/test: add UI test and docs for `E0476`)
- #108449 (Do not lint ineffective unstable trait impl for unresolved trait)
- #108456 (Complete migrating `ast_passes` to derive diagnostics)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Complete migrating `ast_passes` to derive diagnostics
cc #100717
```@rustbot``` label +A-translation
|
|
r=compiler-errors
Do not lint ineffective unstable trait impl for unresolved trait
|
|
docs/test: add UI test and docs for `E0476`
Final undocumented error code. Not entirely sure about wording in the docs.
Part of https://github.com/rust-lang/rust/issues/61137.
r? ```@compiler-errors```
cc ```@compiler-errors```
|
|
Add regression test for #107918
Fixes https://github.com/rust-lang/rust/issues/107918.
r? ```@notriddle```
|
|
Lint against `Iterator::map` receiving a callable that returns `()`
Close #106991
|
|
|
|
|
|
|
|
Make object bound candidates sound in the new trait solver
r? `@lcnr`
|
|
Add check for invalid #[macro_export] arguments
Resolves #107231
Sorry if I made something wrong, this is my first contribution to the repo.
|
|
Implement -Zlink-directives=yes/no
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives.
This is another way to address issue # #70093, which is currently addressed by `-Zlink-native-libraries` (implemented in #70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used.
Being able to control this on a crate-by-crate basis should make it much easier to apply when needed.
I'm not sure if we need both mechanisms, but we can decide that later.
cc `@pcwalton` `@cramertj`
|
|
[breaking change] Remove a rustdoc back compat warning
This warning was introduced in https://github.com/rust-lang/rust/pull/62855 for users who use `rustdoc` directly on proc macro crates (instead of using `cargo doc`) without passing `--crate-type proc-macro` (which `cargo doc` passed automatically).
|
|
Rollup of 7 pull requests
Successful merges:
- #108354 (Update `fuchsia-test-runner.py` and docs)
- #108404 (support `x fmt` for sub and outside of rust directories)
- #108407 (docs: use intra-doc links for `Vec::get(_mut)`)
- #108410 (rustdoc: avoid including `<li>` tags in item table short desc)
- #108412 (Fix GUI test navigation bug)
- #108433 (Wrap missing provider message correctly)
- #108434 (Migrate `rustc_hir_analysis` to session diagnostic [Part One])
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
r=notriddle
Fix GUI test navigation bug
Following https://github.com/GuillaumeGomez/browser-UI-test/pull/438, we can now remove this `wait-for`.
Should help with #93784.
r? ``@notriddle``
|
|
rustdoc: avoid including `<li>` tags in item table short desc
Fixes a bug seen at https://docs.rs/gl_constants/0.1.1/gl_constants/index.html
|
|
Move some std tests from `tests/ui-fulldeps` into `library/std`
This allows them to be tested normally along with other `./x test std` tests. Moving `rename_directory` is simple enough but `create_dir_all_bare` needed to be an std integration test.
Additionally, some tests that I couldn't move atm have instead been placed in an `std` subdirectory. These tests include ones that do fun things with processes or that intentionally abort the test process.
r? libs
|
|
|
|
|
|
Remove dead unwinds before drop elaboration
As a part of drop elaboration, we identify dead unwinds, i.e., unwind
edges on a drop terminators which are known to be unreachable, because
there is no need to drop anything.
Previously, the data flow framework was informed about the dead unwinds,
and it assumed those edges are absent from MIR. Unfortunately, the data
flow framework wasn't consistent in maintaining this assumption.
In particular, if a block was reachable only through a dead unwind edge,
its state was propagated to other blocks still. This became an issue in
the context of change removes DropAndReplace terminator, since it
introduces initialization into cleanup blocks.
To avoid this issue, remove unreachable unwind edges before the drop
elaboration, and elaborate only blocks that remain reachable.
cc `@Zeegomo`
|
|
|
|
r=compiler-errors
diagnostics: remove inconsistent English article "this" from E0107
Consider [`tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`][issue-102768.stderr], the error message where it gives additional notes about where the associated type is defined, and how the dead code lint doesn't have an article, like in [`tests/ui/lint/dead-code/issue-85255.stderr`][issue-85255.stderr]. They don't have articles, so it seems unnecessary to have one here.
[issue-102768.stderr]: https://github.com/rust-lang/rust/blob/07c993eba8b76eae497e98433ae075b00f01be10/tests/ui/const-generics/generic_const_exprs/issue-102768.stderr
[issue-85255.stderr]: https://github.com/rust-lang/rust/blob/07c993eba8b76eae497e98433ae075b00f01be10/tests/ui/lint/dead-code/issue-85255.stderr
|
