tests: add sanity-check assembly test for every target
Fixes#119910.
Adds a basic assembly test checking that each target can produce assembly and update the target tier policy to require this.
cc rust-lang/compiler-team#655
r? `@wesleywiser`
Add way to express that no values are expected with check-cfg
This PR adds way to express no-values (no values expected) with `--check-cfg` by making empty `values()` no longer mean `values(none())` (internal: `&[None]`) and now be an empty list (internal: `&[]`).
### Context
Currently `--check-cfg` has a way to express that _any value is expected_ with `values(any())`, but has no way to do the inverse and say that _no value is expected_.
This would be particularly useful for build systems that control a config name and it's values as they could always declare a config name as expected and if in the current state they have values pass them and if not pass an empty list.
To give a more concrete example, Cargo `--check-cfg` currently needs to generate:
- `--check-cfg=cfg(feature, values(...))` for the case with declared features
- and `--check-cfg=cfg()` for the case without any features declared
This means that when there are no features declared, users will get an `unexpected config name` but from the point of view of Cargo the config name `feature` is expected, it's just that for now there aren't any values for it.
See [Cargo `check_cfg_args` function](92395d9010/src/cargo/core/compiler/mod.rs (L1263-L1281)) for more details.
### De-specializing *empty* `values()`
To solve this issue I propose that we "de-specialize" empty `values()` to no longer mean `values(none())` but to actually mean empty set/list. This is one of the last source of confusion for my-self and others with the `--check-cfg` syntax.
> The confusing part here is that an empty `values()` currently means the same as `values(none())`, i.e. an expected list of values with the _none_ variant (as in `#[cfg(name)]` where the value is none) instead of meaning an empty set.
Before the new `cfg()` syntax, defining the _none_ variant was only possible under certain circumstances, so in https://github.com/rust-lang/rust/pull/111068 I decided to make `values()` to mean the _none_ variant, but it is no longer necessary since https://github.com/rust-lang/rust/pull/119473 which introduced the `none()` syntax.
A simplified representation of the proposed "de-specialization" would be:
| Syntax | List/set of expected values |
|-----------------------------------------|-----------------------------|
| `cfg(name)`/`cfg(name, values(none()))` | `&[None]` |
| `cfg(name, values())` | `&[]` |
Note that I have my-self made the mistake of using an empty `values()` as meaning empty set, see https://github.com/rust-lang/cargo/pull/13011.
`@rustbot` label +F-check-cfg
r? `@petrochenkov`
cc `@epage`
In LLVM 17, PowerPC targets started including function pointer alignments
in data layouts, and in Rust's update to that version (#114048), we added
the function pointer alignments. `powerpc64-unknown-linux-musl` had
`Fi64` set but this seems incorrect, and the code in LLVM would always
have computed `Fn32` because it is a MUSL target.
Signed-off-by: David Wood <david@davidtw.co>
Adds a basic assembly test checking that each target can produce assembly
and update the target tier policy to require this.
Signed-off-by: David Wood <david@davidtw.co>
Rework how diagnostic lints are stored.
`Diagnostic::code` has the type `DiagnosticId`, which has `Error` and
`Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be
redundant w.r.t. `Diagnostic::code`.
Seems simple. Except it's possible for a lint to have an error code, in
which case its `code` field is recorded as `Error`, and `is_lint` is
required to indicate that it's a lint. This is what happens with
`derive(LintDiagnostic)` lints. Which means those lints don't have a
lint name or a `has_future_breakage` field because those are stored in
the `DiagnosticId::Lint`.
It's all a bit messy and confused and seems unintentional.
This commit:
- removes `DiagnosticId`;
- changes `Diagnostic::code` to `Option<String>`, which means both
errors and lints can straightforwardly have an error code;
- changes `Diagnostic::is_lint` to `Option<IsLint>`, where `IsLint` is a
new type containing a lint name and a `has_future_breakage` bool, so
all lints can have those, error code or not.
r? `@oli-obk`
fix fn/const items implied bounds and wf check (rebase)
A rebase of #104098, see that PR for discussion. This is pretty much entirely the work of `@aliemjay.` I received his permission for this rebase.
---
These are two distinct changes (edit: actually three, see below):
1. Wf-check all fn item args. This is a soundness fix.
Fixes#104005
2. Use implied bounds from impl header in borrowck of associated functions/consts. This strictly accepts more code and helps to mitigate the impact of other breaking changes.
Fixes#98852Fixes#102611
The first is a breaking change and will likely have a big impact without the the second one. See the first commit for how it breaks libstd.
Landing the second one without the first will allow more incorrect code to pass. For example an exploit of #104005 would be as simple as:
```rust
use core::fmt::Display;
trait ExtendLt<Witness> {
fn extend(self) -> Box<dyn Display>;
}
impl<T: Display> ExtendLt<&'static T> for T {
fn extend(self) -> Box<dyn Display> {
Box::new(self)
}
}
fn main() {
let val = (&String::new()).extend();
println!("{val}");
}
```
The third change is to to check WF of user type annotations before normalizing them (fixes#104764, fixes#104763). It is mutually dependent on the second change above: an attempt to land it separately in #104746 caused several crater regressions that can all be mitigated by using the implied from the impl header. It is also necessary for the soundness of associated consts that use the implied bounds of impl header. See #104763 and how the third commit fixes the soundness issue in `tests/ui/wf/wf-associated-const.rs` that was introduces by the previous commit.
r? types
Update cargo
10 commits in 84976cd699f4aea56cb3a90ce3eedeed9e20d5a5..1cff2ee6b92e0ad3f87c44b70b28f788b2528b3c
2024-01-12 15:55:43 +0000 to 2024-01-16 16:56:57 +0000
- doc: add a heading to highlight "How to find features enabled on dependencies" (rust-lang/cargo#13305)
- fix(cargo-update): `--precise` accept arbitrary git revisions (rust-lang/cargo#13250)
- Strip debuginfo when debuginfo is not requested (rust-lang/cargo#13257)
- Update ahash dependency to 0.8.7 (rust-lang/cargo#13301)
- docs: add more links to pkgid spec chapter (rust-lang/cargo#13298)
- fix(metadata): Stabilize id format as PackageIDSpec (rust-lang/cargo#12914)
- Introduce `-Zprecise-pre-release` unstable flag (rust-lang/cargo#13296)
- Delete sentence about parentheses being unsupported in license (rust-lang/cargo#13292)
- Add guidance on setting homepage in manifest (rust-lang/cargo#13293)
- Clarify the function of the test options (rust-lang/cargo#13236)
r? ghost
Cache local DefId-keyed queries without hashing
This caches local DefId-keyed queries using just an IndexVec. This costs ~5% extra max-rss at most but brings significant runtime improvement, up to 13% cycle counts (mean: 4%) on primary benchmarks. It's possible that further tweaks could reduce the memory overhead further but this win seems worth landing despite the increased memory, particularly with regards to eliminating the present set in non-incr or storing it inline (skip list?) with the main data.
We tried applying this scheme to all keys in the [first perf run] but found that it carried a significant memory hit (50%). instructions/cycle counts were also much more mixed, though that may have been due to the lack of the present set optimization (needed for fast iter() calls in incremental scenarios).
Closes https://github.com/rust-lang/rust/issues/45275
[first perf run]: https://perf.rust-lang.org/compare.html?start=30dfb9e046aeb878db04332c74de76e52fb7db10&end=6235575300d8e6e2cc6f449cb9048722ef43f9c7&stat=instructions:u
Lint `overlapping_ranges_endpoints` directly instead of collecting into a Vec
In https://github.com/rust-lang/rust/pull/119396 I was a bit silly: I was trying to avoid any lints being fired from within the exhaustiveness algorithm for some vague aesthetic/reusability reason that doesn't really hold. This PR fixes that: instead of passing a `&mut Vec` around I just added a method to the `TypeCx` trait.
r? `@compiler-errors`
Update books
## rust-lang/nomicon
1 commits in f6bd083c4ccfc4ce6699b8b4154e3c45c5a27a8c..6bc2415218d4dd0cb01433d8320f5ccf79c343a1
2024-01-03 04:01:04 UTC to 2024-01-03 04:01:04 UTC
- Update an example of `thread_local` to use `local_key_cell_methods` (rust-lang/nomicon#438)
## rust-lang/reference
1 commits in 3565c7978cfc9662f5963b135690ff9cbbfa0318..8c77e8be9da1a9c70545556218d563c8d061f1fd
2024-01-08 15:16:51 UTC to 2024-01-08 15:16:51 UTC
- Document that <- is a single token (rust-lang/reference#1424)
## rust-lang/rust-by-example
4 commits in c0be6299e52e4164c30ba6f41bd0ad0aaee64972..ddf5cb0e6ee54ba2dd84c8ca3e1314120014e20d
2024-01-13 11:06:22 UTC to 2024-01-13 11:01:00 UTC
- Update attribute.md, (rust-lang/rust-by-example#1791)
- fix: typo `unusude` (rust-lang/rust-by-example#1797)
- Update print.md (rust-lang/rust-by-example#1796)
- Update alias.md (rust-lang/rust-by-example#1790)
## rust-lang/rustc-dev-guide
4 commits in d13e85152a977cd0bcaf583cf5f49e86225697de..4af29d1a7f64f88a36539662c6a84fe1fbe6cde1
2024-01-14 10:42:53 UTC to 2024-01-06 17:47:01 UTC
- Expand upon PR guidelines (rust-lang/rustc-dev-guide#1851)
- Correct the link to rust reference (rust-lang/rustc-dev-guide#1848)
- Explain the important concepts of exhaustiveness checking (rust-lang/rustc-dev-guide#1830)
- Add guide for rustdoc search implementation (rust-lang/rustc-dev-guide#1846)
Add private `NonZero<T>` type alias.
According to step 2 suggested in https://github.com/rust-lang/rust/pull/100428#pullrequestreview-1767139731.
This adds a private type alias for `NonZero<T>` so that some parts of the code can already start using `NonZero<T>` syntax.
Using `NonZero<T>` for `convert` and other parts which implement `From` doesn't work while it is a type alias, since this results in conflicting implementations.
Simplify `closure_env_ty` and `closure_env_param`
Random cleanup that I found when working on async closures. This makes it easier to separate the latter into a new tykind.
Make sure to instantiate placeholders correctly in old solver
When creating the query substitution guess for an input placeholder type like `!1_T` (in universe 1), we were guessing the response substitution with something like `!0_T`. This failed to unify with `!1_T`, causing an ICE.
This PR reworks the query substitution guess code to work a bit more like the new solver. I'm *pretty* sure this is correct, though I'd really appreciate some scrutiny from someone (*cough* lcnr) who knows a bit more about query instantiation :)
Fixes#119941
r? lcnr
Sandwich MIR optimizations between DSE.
This PR reorders MIR optimization passes in an attempt to increase their efficiency.
- Stop running CopyProp before GVN, it's useless as GVN will do the same thing anyway. Instead, we perform CopyProp at the end of the pipeline, to ensure we do not emit copy/move chains.
- Run DSE before GVN, as it increases the probability to have single-assignment locals.
- Run DSE after the final CopyProp to turn copies into moves.
r? `@ghost`
Avoid some redundant work in GVN
The first 2 commits are about reducing the perf effect.
Third commit avoids doing redundant work: is a local is SSA, it already has been simplified, and the resulting value is in `self.locals`. No need to call any code on it.
The last commit avoids removing some storage statements.
r? wg-mir-opt
Foreign maps are used to cache external DefIds, typically backed by
metadata decoding. In the future we might skip caching `V` there (since
loading from metadata usually is already cheap enough), but for now this
cuts down on the impact to memory usage and time to None-init a bunch of
memory. Foreign data is usually much sparser, since we're not usually
loading *all* entries from the foreign crate(s).
never patterns: Check bindings wrt never patterns
Never patterns:
- Shouldn't contain bindings since they never match anything;
- Don't count when checking that or-patterns have consistent bindings.
r? `@compiler-errors`
