Relax ordering rules for `asm!` operands
The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order:
- Template strings
- Positional operands
- Named operands
- Explicit register operands
- `clobber_abi`
- `options`
This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows:
- Template strings must still come before all other operands.
- Positional operands must still come before named and explicit register operands.
- Named and explicit register operands can be freely mixed.
- `options` and `clobber_abi` can appear in any position after the template strings.
r? ```````@joshtriplett```````
Don't even try to combine consts with incompatible types
~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~
1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.
Fixes#108781
feat: implement better error for manual impl of `Fn*` traits
Fixes#39259
cc `@estebank` (you gave me some advice in the linked issue, would you like to review?)
Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type
We never supported solving `for<'a> fn(&'a ()): Fn(&'a ())` -- I tried to add that support in #104929, but iirc `@lcnr` wanted to support this more generally by eagerly instantiating trait predicate binders with placeholders. That never happened due to blockers in the old solver, but we probably shouldn't ICE in any case.
On the bright side, this passes on the new solver :^)
Emit alias-eq when equating numeric var and projection
This doesn't fix everything having to do with projections and infer vars, but it does fix a common case I saw in HIR typeck.
r? `@lcnr`
Rollup of 9 pull requests
Successful merges:
- #108879 (Unconstrained terms should account for infer vars being equated)
- #108936 (Rustdoc: don't hide anonymous reexport)
- #108940 (Add myself to compiler reviewers list)
- #108945 (Make some report and emit errors take DefIds instead of BodyIds)
- #108946 (Document the resulting values produced when using `From<bool>` on floats)
- #108956 (Make ptr::from_ref and ptr::from_mut in #106116 const.)
- #108960 (Remove `body_def_id` from `Inherited`)
- #108963 (only call git on git checkouts during bootstrap)
- #108964 (Fix the docs for pointer method with_metadata_of)
Failed merges:
- #108950 (Directly construct Inherited in typeck.)
r? `@ghost`
`@rustbot` modify labels: rollup
Introduce a no-op `PlaceMention` statement for `let _ =`.
Fixes https://github.com/rust-lang/rust/issues/54003
Fixes https://github.com/rust-lang/rust/issues/80059
Split from https://github.com/rust-lang/rust/pull/101500
This PR introduces a new `PlaceMention` statement dedicated to matches that neither introduce bindings nor ascribe types. Without this, all traces of the match would vanish from MIR, making it impossible to diagnose unsafety or use in #101500.
This allows to mark `let _ = <unsafe union access or dereference>` as requiring an unsafe block.
Nominating for lang team, as this introduces an extra error.
Remove `body_def_id` from `Inherited`
We can just use the body id from the obligation cause.
Follow-up to #108945, only my commit is relevant.
r? `@cjgillot` cc `@spastorino`
Unconstrained terms should account for infer vars being equated
Follow-up from the canonicalization PR, wanted to break this one out so I can approve the other PR.
r? `@lcnr`
This is fixed by simply using the currently registered target in the
current session. We need to use it because of target json that are not
by design included in the rustc list of targets.
feat/refactor: improve errors in case of ident with number at start
Improve parser code when we parse a integer (or float) literal but expect an identifier. We emit an error message saying that identifiers can't begin with numbers. This PR just improves that code and expands it to all identifiers. Note that I haven't implemented error recovery (this didn't exist before anyway), I might do that in a follow up PR.
Rollup of 8 pull requests
Successful merges:
- #108754 (Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous)
- #108759 (1.41.1 supported 32-bit Apple targets)
- #108839 (Canonicalize root var when making response from new solver)
- #108856 (Remove DropAndReplace terminator)
- #108882 (Tweak E0740)
- #108898 (Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap)
- #108911 (Improve rustdoc-gui/tester.js code a bit)
- #108916 (Remove an unused return value in `rustc_hir_typeck`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not consider `&mut *x` as mutating `x` in `CopyProp`
This PR removes an unfortunate overly cautious case from the current implementation.
Found by https://github.com/rust-lang/rust/pull/105274 cc `@saethlin`
Canonicalize root var when making response from new solver
During trait solving, if we equate two inference variables `?0` and `?1` but don't equate them with any rigid types, then `InferCtxt::probe_ty_var` will return `Err` for both of these. The canonicalizer code will then canonicalize the variables independently(!), and the response will not reflect the fact that these two variables have been made equal.
This hinders inference and I also don't think it's sound? I haven't thought too much about it past that, so let's talk about it.
r? ``@lcnr``
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous
Fixes#108721
The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:
f15f0ea739/compiler/rustc_trait_selection/src/traits/select/mod.rs (L596-L606)
... Compared to the analogous loop in the new solver:
f15f0ea739/compiler/rustc_trait_selection/src/solve/mod.rs (L481-L512)
To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.
--
Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/
r? types
Rename `MapInPlace` as `FlatMapInPlace`.
After removing the `map_in_place` method, which isn't much use because modifying every element in a collection such as a `Vec` can be done trivially with iteration.
r? ``@lqd``
Suppress copy impl error when post-normalized type references errors
Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization.
----
The const-generics test regressed recently due to #107965, cc `````@BoxyUwU.`````
* I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails.
* It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
StableMIR: Proof-of-concept implementation + test
This PR is part of the [project Stable MIR](https://github.com/rust-lang/project-stable-mir). The PR deletes old re-exports from rustc_smir and introduces a proof-of-concept implementation for APIs to retrieve crate information.
The implementation follows the [design described here](https://hackmd.io/XhnYHKKuR6-LChhobvlT-g?view), but instead of using separate crates for the implementation, it uses separate modules inside `rustc_smir`.
The API introduced at this point should be seen just as an example on how we are planning to structure the communication between tools and the compiler.
I have not explored yet what should be the right granularity, the best starting point for users, neither the best way to implement it.
r? ``````@oli-obk``````
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
always resolve to universal regions if possible
`RegionConstraintCollector::opportunistic_resolve_var`, which is used in canonicalization and projection logic, doesn't resolve the region var to an equal universal region. So if we have equated `'static == '1 == '2`, it doesn't resolve `'1` or `'2` to `'static`. Now it does!
Addresses review comment https://github.com/rust-lang/rust/pull/107376#discussion_r1093233687.
r? `@lcnr`
In case a variable is unified with two universal regions from different
universes, use the one with the lower universe as it has a higher chance
of being compatible with the variable.
SymbolWrapper.cpp doesn't use std::optional or llvm::Optional, so this
patch removes the extraneous include. Note that llvm/ADT/Optional.h
has been deprecated upstream. This patch ensures that
SymbolWrapper.cpp continues to compile even after the upcoming removal
of Optional.h.
Do not implement HashStable for HashSet (MCP 533)
This PR removes all occurrences of `HashSet` in query results, replacing it either with `FxIndexSet` or with `UnordSet`, and then removes the `HashStable` implementation of `HashSet`. This is part of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533), that is, removing the `HashStable` implementations of all collection types with unstable iteration order.
The changes are mostly mechanical. The only place where additional sorting is happening is in Miri's override implementation of the `exported_symbols` query.
After removing the `map_in_place` method, which isn't much use because
modifying every element in a collection such as a `Vec` can be done
trivially with iteration.
The crate hash is needed:
- if debug assertions are enabled, or
- if incr. comp. is enabled, or
- if metadata is being generated, or
- if `-C instrumentation-coverage` is enabled.
This commit avoids computing the crate hash when these conditions are
all false, such as when doing a release build of a binary crate.
It uses `Option` to store the hashes when needed, rather than
computing them on demand, because some of them are needed in multiple
places and computing them on demand would make compilation slower.
The commit also removes `Owner::hash_without_bodies`. There is no
benefit to pre-computing that one, it can just be done in the normal
fashion.
Account for binders correctly when adding default RPITIT method assumption
As of #108203, we install extra projection predicates into the param-env of a default trait method when it has return-position `impl Trait` (or is async).
The implementation didn't account for the fact that it's walking into and out of binders, so we just need to shift all the debruijn indices accordingly when constructing the projection predicates.
Fixes#108579
r? types
Make `rustc_query_system` take `QueryConfig` by instance.
This allows for easy switching between virtual tables and specialized instances for queries. It also has the benefit of less turbofish. `QueryStorage` has also been merged with `QueryCache`.
Split out from https://github.com/rust-lang/rust/pull/107937.
r? `@cjgillot`
feat: impl better help for `.poll()` not found on `impl Future`
Partially address #108572
I'd like to also address suggestions for generalized `Self` parameters as well. That'll be a separate PR.
Add `round_ties_even` to `f32` and `f64`
Tracking issue: #96710
Redux of #82273. See also #55107
Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this.
Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`). Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight.
Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
Remove `allow(potential_query_instability)` from `borrowck`
cc #84447
Replace uses of `FxHash*` with `FxIndex*`. One `#[allow]` for a HashMap in an external crate but the output is sorted afterwards.
fix multiple issues when promoting type-test subject
Multiple interdependent fixes. See linked issues for a short description of each.
When Promoting a type-test `T: 'a` from within the closure back to its parent function, there are a couple pre-existing bugs and limitations. They were exposed by the recent changes to opaque types because the type-test subject (`T`) is no longer a simple ParamTy.
Commit 1:
Fixes#108635Fixes#107426
Commit 2:
Fixes#108639
Commit 3:
Fixes#107516
Rollup of 8 pull requests
Successful merges:
- #107801 (const_eval: `implies_by` in `rustc_const_unstable`)
- #108750 (Fix `ObligationCtxt::sub`)
- #108780 (Add regression tests for issue 70919)
- #108786 (Check for free regions in MIR validation)
- #108790 (Do not ICE when interpreting a cast between non-monomorphic types)
- #108803 (Do not ICE when failing to normalize in ConstProp.)
- #108807 (Emit the suspicious_auto_trait_impls for negative impls as well)
- #108812 (Add regression test for #98444)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not ICE when failing to normalize in ConstProp.
There is no reason to delay a bug there, as we bubble up the failure as TooGeneric.
Fixes https://github.com/rust-lang/rust/issues/97728
Check for free regions in MIR validation
This turns https://github.com/rust-lang/rust/issues/108720 into a MIR validation failure that will reproduce without debug-assertions enabled.
```
error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:296 ~ futures_util[3805]::future::future::remote_handle::{impl#3}::poll), const_param_did: None }) (after pass ScalarReplacementOfAggregates) at bb0[0]:
Free regions in optimized runtime-post-cleanup MIR
--> /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.26/src/future/future/remote_handle.rs:96:13
|
96 | let this = self.project();
| ^^^^
```
const_eval: `implies_by` in `rustc_const_unstable`
Fixes#107605.
Extend support for `implies_by` (from `#[stable]` and `#[unstable]`) to `#[rustc_const_stable]` and `#[rustc_const_unstable]`.
cc ``@steffahn``
Allow using `bool` instead of `Option<()>` in diagnostics
~~Disallow the unit type for `#[help]`, `#[note]` etc, instead using `bool` to express optional annotations without a span which I believe is more intuitive.~~
~~Test output ordering has changed in a few places, where a field was of type `()` and the annotation has been moved to the struct itself. If any of these changes are an issue, this can be restricted to allowing specifically `()`, and not `Option<()>`~~
~~Actual changes here: https://github.com/rust-lang/rust/pull/108402/files#diff-815b1d8debfc564112bd51093791d7c3f2ee288a37a8f5c0e89c11d1f609b4c0~~
Allows using `bool` in derive diagnostics to indicate an optional subdiagnostic without a span, where previously `Option<()>` had to be used
`@rustbot` label +A-diagnostics
rustc_middle: Remove trait `DefIdTree`
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
Desugaring of drop and replace at MIR build
This commit desugars the drop and replace deriving from an
assignment at MIR build, avoiding the construction of the
`DropAndReplace` terminator (which will be removed in a following PR).
In order to retain the same error messages for replaces a new
`DesugaringKind::Replace` variant is introduced.
The changes in the borrowck are also useful for future work in moving drop elaboration
before borrowck, as no `DropAndReplace` would be present there anymore.
Notes on test diffs:
* `tests/ui/borrowck/issue-58776-borrowck-scans-children`: the assignment deriving from the desugaring kills the borrow.
* `tests/ui/async-await/async-fn-size-uninit-locals.rs`, `tests/mir-opt/issue_41110.test.ElaborateDrops.after.mir`, `tests/mir-opt/issue_41888.main.ElaborateDrops.after.mir`: drop elaboration generates (or reads from) a useless drop flag due to an issue with the dataflow analysis. Will be fixed independently by https://github.com/rust-lang/rust/pull/106430.
See https://github.com/rust-lang/rust/pull/104488 for more context
Make compressed rmeta contain compressed data length after header
Fixes#90056, which is caused by link.exe introducing padding to the `.rustc` section, since it assumes this will have no effect besides allowing it to possibly use the extra space in future links.
Fuchsia is in the process of implementing the RISC-V support. This
change implements the minimal Rust compiler support. The support for
building runtime libraries will be implemented in follow up changes
once Fuchsia SDK has the RISC-V support.
Don't call `temporary_scope` twice.
`mirror_expr_inner` calls `temporary_scope`. It then calls `make_mirror_unadjusted` which makes an identical call to `temporary_scope`.
This commit changes the `mirror_expr_inner` to get the `temp_lifetime` out of the expression produced by `make_mirror_unadjusted`, similar to how it currently gets the type.
r? `@cjgillot`
rustc_expand: make proc-macro derive error translatable
kept this tiny so as to point to it as an example in rustc-dev-guide
`@rustbot` label +A-translation
Remove `NormalizationError::ConstantKind`
No longer in use by `TryNormalizeAfterErasingRegionsFolder` (as of #102355 / e8150fa60c it seems). It's making `LayoutError`, etc. kinda large -- that was noticed by `@zoxc.`
Use `Option::as_slice` where applicable
After #105871 introduced `Option::as_slice`, this PR uses it within the compiler. I found it interesting that all cases where `as_slice` could be used were done with different code before; so it seems the new API also has the benefit of being "the obvious solution" where before there was a mix of options, none clearly better than the rest.
Label opaque type for 'captures lifetime' error message
Providing more information may help make this somewhat opaque (lol) error message a bit clearer.
Fix another ICE in `point_at_expr_source_of_inferred_type`
Types coming from method probes must only be investigated *structurally*, since they often contain escaping infer variables from generalization and autoderef. We already have a hack in this PR that erases variables from types, so just use that.
Fixes#108664
The note attached to this error is pretty bad:
```
here the type of `primes` is inferred to be `[_]`
```
But that's unrelated to the PR.
---
Side-note: This is a pretty easy to trigger beta regression, so I've nominated it. Alternatively, I'm slightly inclined to remove this code altogether until it can be reformulated to be more accurate and less ICEy.
Remove legacy PM leftovers
This drops two leftovers of legacy PM usage:
* We don't need to initialize passes anymore.
* The pass listing was still using legacy PM passes. Replace it with the corresponding new PM listing.
Deny capturing late-bound non-lifetime param in anon const
Introduce a new AnonConstBoundary so we can detect when we capture a late-bound non-lifetime param with `non_lifetime_binders` enabled.
In the future, we could technically do something like introduce an early-bound parameter on the anon const, and stick the late-bound param in its substs (kinda like how we turn late-bound lifetimes in opaques into early-bound ones). But for now, just deny it so we don't ICE.
Fixes#108191
This commit desugars the drop and replace deriving from an
assignment at MIR build, avoiding the construction of the
DropAndReplace terminator (which will be removed in a followign PR)
In order to retain the same error messages for replaces a new
DesugaringKind::Replace variant is introduced.
`mirror_expr_inner` calls `temporary_scope`. It then calls
`make_mirror_unadjusted` which makes an identical call to
`temporary_scope`.
This commit changes the `mirror_expr_inner` to get the `temp_lifetime`
out of the expression produced by `make_mirror_unadjusted`, similar to
how it currently gets the type.
Feed queries on impl side for RPITITs when using lower_impl_trait_in_trait_to_assoc_ty
I've added a test for traits that were already working and what I think is probably the last bit of infrastructure work needed.
In following PRs I'm going to start adding things TDD style, tests and code that make it work.
r? `@compiler-errors`
Make `ExprKind` the first field in `thir::Expr`
This makes its `Debug` impl print it first which is useful, as it's the most important part when looking at an expr.
Explain compile-time vs run-time difference in env!() error message
This PR is clarifying error message of `env!()` based on this user question: https://users.rust-lang.org/t/environment-variable-out-dir-is-undefined/90067
It makes it clear that `env!()` is for env variables defined at compile-time. There's special-case help text for common Cargo build script variables.
I've also rearranged the code to avoid allocating error message on the happy path when the env var is defined.
Point error span at Some constructor argument when trait resolution fails
This is a follow up to #108254 and #106477 which extends error span refinement to handle a case which I mistakenly believed was handled in #106477. The goal is to refine the error span depicted below:
```rs
trait Fancy {}
impl <T> Fancy for Option<T> where T: Iterator {}
fn want_fancy<F>(f: F) where F: Fancy {}
fn example() {
want_fancy(Some(5));
// (BEFORE) ^^^^^^^ `{integer}` is not an iterator
// (AFTER) ^ `{integer}` is not an iterator
}
```
I had used a (slightly more complex) example as an illustrative example in #108254 , but hadn't actually turned it into a test, because I had (incorrectly) believed at the time it was covered by existing behavior. It turns out that `Some` is slightly "special" in that it resolves differently from the other `enum` constructors I had tried, and therefore this test was actually broken.
I've now updated the tests to include this example, and fixed the code to correctly resolve the `Some` constructor so that the span of the error is reduced.
Support allocations with non-Box<[u8]> bytes
This is prep work for allowing miri to support passing pointers to C code, which will require `Allocation`s to be correctly aligned. Currently, it just makes `Allocation` generic and plumbs the necessary changes through the right places.
The follow-up to this will be adding a type in the miri interpreter which correctly aligns the bytes, using that for the Miri engine, then allowing Miri to pass pointers into these allocations to C calls.
Based off of #100467, credit to ```@emarteca``` for the code
Revert stabilization of `#![feature(target_feature_11)]`
This reverts #99767 due to the presence of bugs #108645 and #108646.
cc `@joshtriplett`
cc tracking issue #69098
r? `@ghost`
Highlight whole expression for E0599
Fixes#108603
This adds a secondary label to highlight the whole expression leading to the error. It also prevents empty labels being recognised as 'unexpected' by compiletest - otherwise, tests with NOTE annotations would pick up empty labels.
`@rustbot` label +A-diagnostics
Restrict `#[rustc_box]` to `Box::new` calls
Currently, `#[rustc_box]` can be applied to any call expression with a single argument. This PR only allows it to be applied to calls to `Box::new`
Rollup of 7 pull requests
Successful merges:
- #108143 (rustdoc: search by macro when query ends with `!`)
- #108394 (Make `x doc --open` work on every book)
- #108427 (Recover from for-else and while-else)
- #108462 (Fix `VecDeque::append` capacity overflow for ZSTs)
- #108568 (Make associated_item_def_ids for traits use an unstable option to also return associated types for RPITITs)
- #108604 (Add regression test for #107280)
- #108605 (Add regression test for #105821)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Name LLVM anonymous constants by a hash of their contents
This makes the names stable between different versions of a crate unlike the `AllocId` naming, making LLVM IR comparisons with `llvm-diff` more practical.
Fix a race in the query system
This fixes an issue where in between the `job` removal and `complete` call the query neither has a job nor a result, allowing another thread to start executing it again.
r? ``@cjgillot``
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
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/`](b67ba9ba20/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
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.
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
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.
Emit the enum discriminant separately for the Encodable macro
This changes the `Encodable` proc macro to first emit the discriminant with a separate `match` statement, then emit the fields. LLVM can optimize down the first `match` to just a read of the enum discriminant. This avoids generating a `emit_usize` call per variant and enums with no fields now optimize down to just a single `emit_usize` call.
The no variant case is special cased to avoid warnings about unreachable code.
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.4676s</td><td align="right">0.4640s</td><td align="right"> -0.78%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1348s</td><td align="right">0.1338s</td><td align="right"> -0.75%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.3370s</td><td align="right">0.3352s</td><td align="right"> -0.54%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.6326s</td><td align="right">0.6281s</td><td align="right"> -0.71%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:unchanged</td><td align="right">1.8561s</td><td align="right">1.8589s</td><td align="right"> 0.15%</td></tr><tr><td>Total</td><td align="right">3.4282s</td><td align="right">3.4200s</td><td align="right"> -0.24%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9947s</td><td align="right"> -0.53%</td></tr></table>
Upgrade to ena-0.14.1.
It avoids some inlining within its `inlined_probe_value` function, which seems to result in better codegen for the very large `process_obligations` function within rustc. It might also help with reducing the bimodal perf results we see for the `keccak` and `cranelift-codegen-0.82.1` benchmarks.
r? `@ghost`
Remove `from` lang item
It was probably a leftover from the old `?` desugaring but anyways, it's unused now except for clippy, which can just use a diagnostics item.
statically guarantee that current error codes are documented
Closes#61137 (that's right!)
Pretty simple refactor (often just a change from `Result<Option<&str>>` to `Result<&str>`)
r? `@GuillaumeGomez` (could you specially look at 53044158eff0d64673a6100f701c57b484232aca? I believe you wrote that in the first place, just want to make sure you're happy with the change)
rustc_infer: Consolidate obligation elaboration de-duplication
# Explanation
The obligations `Elaborator` is doing de-duplication of obligations in 3 different locations. 1 off which has a comment.
This PR consolidates the functionality and comment to a single function.
Replace parse_[sth]_expr with parse_expr_[sth] function names
This resolves an inconsistency in naming style for functions on the parser, where:
* functions parsing specific kinds of items are named `parse_item_[sth]` and
* functions parsing specific kinds of *expressions* are named `parse_[sth]_expr`
favoring the style used by functions for items. There are multiple advantages of that style:
* functions of both categories are collected in the same place in the [rustdoc output](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html).
* it helps with autocompletion, as you can narrow down your search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. `std::collections::hash_map::Entry`.
The disadvantage is that it doesn't "read like a sentence" any more. But I think the advantages weigh more greatly.
This change was mostly application of this command:
```
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
```
Plus very minor fixes outside of `rustc_parse`, and an invocation of `x fmt`.
Add `ErrorGuaranteed` to `hir::{Expr,Ty}Kind::Err` variants
First step in making the `Err` variants of `ExprKind` and `TyKind` require an `ErrorGuaranteed` during parsing. Making the corresponding AST versions require `ErrorGuaranteed` is a bit harder, whereas it was pretty easy to do this for HIR, so let's do that first.
The only weird thing about this PR is that `ErrorGuaranteed` is moved to `rustc_span`. This is *certainly* not the right place to put it, but `rustc_hir` cannot depend on `rustc_error` because the latter already depends on the former. Should I just pull out some of the error machinery from `rustc_error` into an even more minimal crate that `rustc_hir` can depend on? Advice would be appreciated.
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
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```
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).
Wrap missing provider message correctly
Fixes#108429
```
error: internal compiler error: compiler/rustc_middle/src/ty/query.rs:441:1: `tcx.trigger_delay_span_bug(DefId(0:3 ~ test[78c5]::main))` is not supported for local crate;
hint: Queries can be either made to the local crate, or the external crate. This error means you tried to use it for one that's not supported.
If that's not the case, trigger_delay_span_bug was likely never assigned to a provider function.
thread 'rustc' panicked at 'Box<dyn Any>', /home/ec2-user/rust3/compiler/rustc_errors/src/lib.rs:1651:9
stack backtrace:
0: 0x7f51870926d7 - std::backtrace_rs::backtrace::libunwind::trace::hb0876bb39e7adf0d
at /home/ec2-user/rust3/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7f51870926d7 - std::backtrace_rs::backtrace::trace_unsynchronized::h1bcab1313827007b
at /home/ec2-user/rust3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7f5187077e07 - std::sys_common::backtrace::_print_fmt::h262d2a62279fa102
at /home/ec2-user/rust3/library/std/src/sys_common/backtrace.rs:65:5
```
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`
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]: 07c993eba8/tests/ui/const-generics/generic_const_exprs/issue-102768.stderr
[issue-85255.stderr]: 07c993eba8/tests/ui/lint/dead-code/issue-85255.stderr
parser: provide better suggestions and errors on closures with braces missing
We currently provide wrong suggestions and unhelpful errors on closure bodies with braces missing.
For example, given the following code:
```rust
fn main() {
let _x = Box::new(|x|x+1;);
}
```
the current output is:
```
error: expected expression, found `)`
--> ./main.rs:2:30
|
2 | let _x = Box::new(|x|x+1;);
| ^ expected expression
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^
3 | }
| ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ this is the parsed closure...
3 | }
| - ...but likely you meant the closure to end here
help: try adding braces
|
2 ~ let _x = Box::new(|x| {x+1;);
3 ~ }}
|
error: expected `;`, found `}`
--> ./main.rs:2:32
|
2 | let _x = Box::new(|x|x+1;);
| ^ help: add `;` here
3 | }
| - unexpected token
error: aborting due to 3 previous errors
```
We got 3 errors, but all but the second are unnecessary or just wrong.
This commit allows outputting correct suggestions and errors. The above code would output like this:
```
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^ ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ - ...but likely you meant the closure to end here
| |
| this is the parsed closure...
help: try adding braces
|
2 | let _x = Box::new(|x| {x+1;});
| + +
error: aborting due to previous error
```
Fixes https://github.com/rust-lang/rust/issues/107959.
r? diagnostics
Fix ICE in 'duplicate diagnostic item' diagnostic
Not sure how to add this in a test; I found it by mistakenly running `cargo fix --lib -p std` rather than `x fix` at the root.
implement const iterator using `rustc_do_not_const_check`
Previous experiment: #102225.
Explanation: rather than making all default methods work under `const` all at once, this uses `rustc_do_not_const_check` as a workaround to "trick" the compiler to not run any checks on those other default methods. Any const implementations are only required to implement the `next` method. Any actual calls to the trait methods other than `next` will either error in compile time (at CTFE runs), or run the methods correctly if they do not have any non-const operations. This is extremely easy to maintain, remove, or improve.
This resolves an inconsistency in naming style for functions
on the parser, between functions parsing specific kinds of items
and those for expressions, favoring the parse_item_[sth] style
used by functions for items. There are multiple advantages
of that style:
* functions of both categories are collected in the same place
in the rustdoc output.
* it helps with autocompletion, as you can narrow down your
search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things
come first, then it gets more specific, i.e.
std::collections::hash_map::Entry
The disadvantage is that it doesn't "read like a sentence"
any more, but I think the advantages weigh more greatly.
This change was mostly application of this command:
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
Plus very minor fixes outside of rustc_parse, and an invocation
of x fmt.
(This is a large commit. The changes to
`compiler/rustc_middle/src/ty/context.rs` are the most important ones.)
The current naming scheme is a mess, with a mix of `_intern_`, `intern_`
and `mk_` prefixes, with little consistency. In particular, in many
cases it's easy to use an iterator interner when a (preferable) slice
interner is available.
The guiding principles of the new naming system:
- No `_intern_` prefixes.
- The `intern_` prefix is for internal operations.
- The `mk_` prefix is for external operations.
- For cases where there is a slice interner and an iterator interner,
the former is `mk_foo` and the latter is `mk_foo_from_iter`.
Also, `slice_interners!` and `direct_interners!` can now be `pub` or
non-`pub`, which helps enforce the internal/external operations
division.
It's not perfect, but I think it's a clear improvement.
The following lists show everything that was renamed.
slice_interners
- const_list
- mk_const_list -> mk_const_list_from_iter
- intern_const_list -> mk_const_list
- substs
- mk_substs -> mk_substs_from_iter
- intern_substs -> mk_substs
- check_substs -> check_and_mk_substs (this is a weird one)
- canonical_var_infos
- intern_canonical_var_infos -> mk_canonical_var_infos
- poly_existential_predicates
- mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter
- intern_poly_existential_predicates -> mk_poly_existential_predicates
- _intern_poly_existential_predicates -> intern_poly_existential_predicates
- predicates
- mk_predicates -> mk_predicates_from_iter
- intern_predicates -> mk_predicates
- _intern_predicates -> intern_predicates
- projs
- intern_projs -> mk_projs
- place_elems
- mk_place_elems -> mk_place_elems_from_iter
- intern_place_elems -> mk_place_elems
- bound_variable_kinds
- mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter
- intern_bound_variable_kinds -> mk_bound_variable_kinds
direct_interners
- region
- intern_region (unchanged)
- const
- mk_const_internal -> intern_const
- const_allocation
- intern_const_alloc -> mk_const_alloc
- layout
- intern_layout -> mk_layout
- adt_def
- intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid)
- alloc_adt_def(!) -> mk_adt_def
- external_constraints
- intern_external_constraints -> mk_external_constraints
Other
- type_list
- mk_type_list -> mk_type_list_from_iter
- intern_type_list -> mk_type_list
- tup
- mk_tup -> mk_tup_from_iter
- intern_tup -> mk_tup
All the slice interners have a wrapper that handles the empty slice
case. We can instead handle this in the `slice_interners!` macro,
avoiding the need for most of the wrappers, and allowing the interner
functions to be renamed from `_intern_foos` to `intern_foos`.
The two exceptions:
- intern_predicates: I kept this wrapper because there's a FIXME
comment about a possible future change.
- intern_poly_existential_predicates: I kept this wrapper because it
asserts that the slice is empty and sorted.
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, 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.
Consider `tests/ui/const-generics/generic_const_exprs/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`. They don't have
articles, so it seems unnecessary to have one here.
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.
We currently provide wrong suggestions and unhelpful errors on closure
bodies with braces missing. For example, given the following code:
```
fn main() {
let _x = Box::new(|x|x+1;);
}
```
the current output is like this:
```
error: expected expression, found `)`
--> ./main.rs:2:30
|
2 | let _x = Box::new(|x|x+1;);
| ^ expected expression
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^
3 | }
| ^
|
...
help: try adding braces
|
2 ~ let _x = Box::new(|x| {x+1;);
3 ~ }}
...
error: expected `;`, found `}`
--> ./main.rs:2:32
|
2 | let _x = Box::new(|x|x+1;);
| ^ help: add `;` here
3 | }
| - unexpected token
error: aborting due to 3 previous errors
```
This commit allows outputting correct suggestions and errors. The above
code would output like this:
```
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^ ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ - ...but likely you meant the closure to end here
| |
| this is the parsed closure...
help: try adding braces
|
2 | let _x = Box::new(|x| {x+1;});
| + +
error: aborting due to previous error
```
Use `tcx.ty_error_with_guaranteed` in more places, rename variants
1. Use `ty_error_with_guaranteed` more so we don't delay so many span bugs
2. Rename `ty_error_with_guaranteed` to `ty_error`, `ty_error` to `ty_error_misc`. This is to incentivize using the former over the latter in cases where we already are witness to a `ErrorGuaranteed` token.
Second commit is just name replacement, so the first commit can be reviewed on its own with more scrutiny.
Use associated type bounds in some places in the compiler
Use associated type bounds for some nested `impl Trait<Assoc = impl Trait2>` cases. I'm generally keen to introduce new lang features that are more mature into the compiler, but maybe let's see what others think?
Side-note: I was surprised that the only use-cases of nested impl trait in the compiler are just iterator related?!
Correctly handle aggregates in DataflowConstProp
The previous implementation from https://github.com/rust-lang/rust/pull/107411 flooded target of an aggregate assignment with `Bottom`, corresponding to the `deinit` that the interpreter does.
As a consequence, when assigning `target = Enum::Variant#i(...)` all the `(target as Variant#j)` were at `Bottom` while they should have been `Top`.
This PR replaces that flooding with `Top`.
Aside, it corrects a second bug where the wrong place would be used to assign to enum variant fields, resulting to nothing happening.
Fixes https://github.com/rust-lang/rust/issues/108166
Ban associated type bounds in bad positions
We should not try to lower associated type bounds into TAITs in positions where `impl Trait` is not allowed (except for in `where` clauses, like `where T: Trait<Assoc: Bound>`).
This is achieved by using the same `rustc_ast_lowering` machinery as impl-trait does to characterize positions as universal/existential/disallowed.
Fixes#106077
Split out the first commit into #108066, since it's not really related.
apply query response: actually define opaque types
not sure whether this fixes any code considering that #107891 doesn't break anything, but this is currently wrong as the `eq` there should just always fail right now.
We can definitely hit this code if we remove the `replace_opaque_types_with_inference_vars` hack. Doing so without this PR causes a few tests to ICE, e.g.
bd4a96a12d/tests/ui/impl-trait/issue-99642.rs (L1-L7)
r? `@oli-obk`
Lint dead code in closures and generators
Fixes#108296
I think this might be a potentially breaking change, but restores the behaviour of pre-1.64.
`@rustbot` label +A-lint
Don't delay `ReError` bug during lexical region resolve
Lexical region resolution returns a list of `RegionResolutionError` which don't necessarily correspond to diagnostics being emitted. The compiler may, validly, throw away these resolution errors and do something else. Therefore it's not valid to use `ReError` during lifetime resolution, since we may actually be on a totally fine compilation path.
For example, the `implied_bounds_entailment` lint runs region resolution twice, and only emits an error if it fails both times. If we delay a bug and create a `ReError` during this first run, then we will ICE.
Fixes#108170
----
Side-note: this is conceptually equivalent to how we can't necessarily delay bugs or create `ty::Error` during trait solving/fulfillment, since the compiler is allowed to throw away these fulfillment errors to do other things. It's only once we actually emit an error (`report_region_errors` / `report_fulfillment_errors`)
Remove type-traversal trait aliases
#107924 moved the type traversal (folding and visiting) traits into the type library, but created trait aliases in `rustc_middle` to minimise both the API churn for trait consumers and the arising boilerplate. As mentioned in that PR, an alternative approach of defining subtraits with blanket implementations of the respective supertraits was also considered at that time but was ruled out as not adding much value.
Unfortunately, it has since emerged that rust-analyzer has difficulty with these trait aliases at present, resulting in a degraded contributor experience (see the recent [r-a has become useless](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/r-a.20has.20become.20useless) topic on the #t-compiler/help Zulip stream).
This PR removes the trait aliases, and accordingly the underlying type library traits are now used directly; they are parameterised by `TyCtxt<'tcx>` rather than just the `'tcx` lifetime, and imports have been updated to reflect the fact that the trait aliases' explicitly named traits are no longer automatically brought into scope. These changes also roll-back the (no-longer required) workarounds to #107747 that were made in b409329c62.
Since this PR is just a find+replace together with the changes necessary for compilation & tidy to pass, it's currently just one mega-commit. Let me know if you'd like it broken up.
r? `@oli-obk`
`-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.
errors: generate typed identifiers in each crate
Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter.
There are advantages and disadvantages to this change..
#### Advantages
- Changing a diagnostic now only recompiles the crate for that diagnostic and those crates that depend on it, rather than `rustc_error_messages` and all crates thereafter.
- This approach can be used to support first-party crates that want to supply translatable diagnostics (e.g. `rust-lang/thorin` in https://github.com/rust-lang/rust/pull/102612#discussion_r985372582, cc `@JhonnyBillM)`
- We can extend this a little so that tools built using rustc internals (like clippy or rustdoc) can add their own diagnostic resources (much more easily than those resources needing to be available to `rustc_error_messages`)
#### Disadvantages
- Crates can only refer to the diagnostic messages defined in the current crate (or those from dependencies), rather than all diagnostic messages.
- `rustc_driver` (or some other crate we create for this purpose) has to directly depend on *everything* that has error messages.
- It already transitively depended on all these crates.
#### Pending work
- [x] I don't know how to make `rustc_codegen_gcc`'s translated diagnostics work with this approach - because `rustc_driver` can't depend on that crate and so can't get its resources to provide to the diagnostic emission. I don't really know how the alternative codegen backends are actually wired up to the compiler at all.
- [x] Update `triagebot.toml` to track the moved FTL files.
r? `@compiler-errors`
cc #100717
Rollup of 8 pull requests
Successful merges:
- #108110 (Move some `InferCtxt` methods to `EvalCtxt` in new solver)
- #108168 (Fix ICE on type alias in recursion)
- #108230 (Convert a hard-warning about named static lifetimes into lint "unused_lifetimes")
- #108239 (Fix overlapping spans in removing extra arguments)
- #108246 (Add an InstCombine for redundant casts)
- #108264 (no-fail-fast support for tool testsuites)
- #108310 (rustdoc: Fix duplicated attributes for first reexport)
- #108318 (Remove unused FileDesc::get_cloexec)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix overlapping spans in removing extra arguments
Fixes#108225
Each span is already extended to include the previous comma, so extending to the *next* comma is unecessary and causes an ICE with assertions on.
``@rustbot`` label +A-diagnostics
Convert a hard-warning about named static lifetimes into lint "unused_lifetimes"
Fixes https://github.com/rust-lang/rust/issues/96956.
Some changes are ported from https://github.com/rust-lang/rust/pull/98079, thanks to jeremydavis519.
r? `@estebank` `@petrochenkov`
Any feedback is appreciated!
## Actions
- [x] resolve conflicts
- [x] fix build
- [x] address review comments in last pr
- [x] update tests
Move some `InferCtxt` methods to `EvalCtxt` in new solver
Moving towards eventually making the `InferCtxt` within `EvalCtxt` private, so that we make sure not to do anything strange in the solver. This doesn't finish this work yet, just gets it started.
r? ``@lcnr``
Extend `CodegenBackend` trait with a function returning the translation
resources from the codegen backend, which can be added to the complete
list of resources provided to the emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
`run-make/translation` had some targets that weren't listed in `all` and
thus weren't being tested - the behaviour that should have been being
tested was basically correct fortunately.
Signed-off-by: David Wood <david.wood@huawei.com>
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
Use a lock-free datastructure for source_span
follow up to the perf regression in https://github.com/rust-lang/rust/pull/105462
The main regression is likely the CStore, but let's evaluate the perf impact of this on its own
Define the `named_static_lifetimes` lint
This lint will replace the existing hard-warning.
Replace the named static lifetime hard-warning with the new lint
Update the UI tests for the `named_static_lifetimes` lint
Remove the direct dependency on `rustc_lint_defs`
fix build
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
use "UNUSED_LIFETIMES" instead
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
update 1 test and fix typo
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
update tests
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
fix tests: add extra blank line
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
Use DefKind to give more item kind information during BindingObligation note
The current label says "required by a bound in this". When I see that label, my immediate impression is "this... **what**?". It feels like it was cut short.
Alternative to this would be saying "in this item", but adding the item kind is strictly more informational and adds very little overhead to the existing error presentation.
Better debug logs for borrowck constraint graph
It's really cumbersome to work with `RegionVar`s when trying to debug borrowck code or when trying to understand how the borrowchecker works. This PR collects some region information (behind `cfg(debug_assertions)`) for created `RegionVar`s (NLL region vars, this PR doesn't touch canonicalization) and prints the nodes and edges of the strongly connected constraints graph using representatives that use that region information (either lifetime names, locations in MIR or spans).
Linker: use -z <params> instead of -z<params>
The GNU linker accepts -z<params>, but this is undocumented, and not supported by other linkers.
In particular, `zig cc`, when used as the C compiler/linker (e.g. when using `cargo-zigbuild`), will not accept this undocumented syntax.
In `linker.rs`, both syntaxes are also used inconsistently.
The Go compiler used to have the same issue, but fixed it:
38607c5538
Make hidden type registration opt-in, so that each site can be reviewed on its own and we have the right defaults for trait solvers
r? `@lcnr`
pulled out of https://github.com/rust-lang/rust/pull/107891 as it is the uncontroversial part
The GNU linker accepts -z<params>, but this is undocumented, and
not supported by other linkers.
In particular, `zig cc`, when used as the C compiler/linker
(e.g. when using `cargo-zigbuild`), will not accept this
undocumented syntax.
In `linker.rs`, both syntaxes are also used inconsistently.
The Go compiler used to have the same issue, but fixed it:
38607c5538
Move `Fn*` traits malformedness protections to typeck
I found it strange that we were doing a custom well-formedness check just for the `Fn*` traits' `call_*` fn items. My understanding from the git history is that this is just to avoid ICEs later on in typeck.
Well, that well-formedness check isn't even implemented correctly for `FnOnce::call_once`, or `FnMut::call_mut` for that matter. Instead, this PR just makes the typeck checks more robust, and leaves it up to the call-site to report errors when lang items are implemented in funny ways.
This coincidentally fixes another ICE where a the `Add` lang item is implemented with a `add` item that's a const instead of a method.
Name placeholder in some region errors
Also don't print `ReVar` or `ReLateBound` as debug... these error messages are super uncommon anyways, but in the case they do trigger, let's be slightly more helpful.
remove unstable `pick_stable_methods_before_any_unstable` flag
This flag was only added in #90329 in case there was any issue with the impl so that it would be easy to tell nightly users to use the flag to disable the new logic to fix their code. It's now been enabled for two years and also I can't find any issues corresponding to this new functionality? This flag made it way harder to understand how this code works so it would be nice to remove it and simplify what's going on.
cc `@nbdd0121`
r? `@oli-obk`
Add rpitit queries
This is part of the changes we are making to lower RPITITs as an associated type. The rest of the stuff will follow under a `-Z` flag.
I still need to add comments to the code, explain stuff and also I'd need to avoid encoding in metadata when rpitit queries return `&[]`
r? `@compiler-errors`
lint: don't suggest MaybeUninit::assume_init for uninhabited types
Creating a zeroed uninhabited type such as `!` or an empty enum with `mem::zeroed()` (or transmuting `()` to `!`) currently triggers this lint:
```rs
warning: the type `!` does not permit zero-initialization
--> test.rs:5:23
|
5 | let _val: ! = mem::zeroed();
| ^^^^^^^^^^^^^
| |
| this code causes undefined behavior when executed
| help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
|
= note: the `!` type has no valid value
```
The `MaybeUninit` suggestion in the help message seems confusing/useless for uninhabited types, as such a type cannot be fully initialized in the first place (as the note implies).
This PR limits this help message to inhabited types which can be initialized
Miri: basic dyn* support
As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something.
TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all.
Strangely I did not need to do the equivalent of [this diff](https://github.com/rust-lang/rust/pull/106532#discussion_r1087095963) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized!
r? `@oli-obk` Cc `@eholk` (dyn-star) https://github.com/rust-lang/rust/issues/102425
Remove old FIXME that no longer applies
it looks like Encodable was fallible at some point, but that was changed which means that this FIXME is no longer applicable
Remove old FIXMEs referring to #19596
Having an inner function that accepts a mutable reference seems to be the only way this can be expressed. Taking a mutable reference would call the same function with a new type &mut F which then causes the infinite recursion error in #19596.
Refine error span for trait error into borrowed expression
Extends the error span refinement in #106477 to drill into borrowed expressions just like tuples/struct/enum literals. For example,
```rs
trait Fancy {}
trait Good {}
impl <'a, T> Fancy for &'a T where T: Good {}
impl <S> Good for Option<S> where S: Iterator {}
fn want_fancy<F>(f: F) where F: Fancy {}
fn example() {
want_fancy(&Some(5));
// (BEFORE) ^^^^^^^^ `{integer}` is not an iterator
// (AFTER) ^ `{integer}` is not an iterator
}
```
Existing heuristics try to find the right part of the expression to "point at"; current heuristics look at e.g. struct constructors and tuples. This PR adds a new check for borrowed expressions when looking into a borrowed type.
Use restricted Damerau-Levenshtein distance for diagnostics
This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a _restricted_ implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.
This was first brought up [on IRLO](https://internals.rust-lang.org/t/18227) when it was noticed that the diagnostic for `prinltn!` (transposed L and T) was `print!` and not `println!`. Only a single existing UI test was effected, with the result being an objective improvement.
~~I have left the method name and various other references to the Levenshtein algorithm untouched, as the exact manner in which the edit distance is calculated should not be relevant to the caller.~~
r? ``@estebank``
``@rustbot`` label +A-diagnostics +C-enhancement
create dummy placeholder crate to prevent compiler from panicing
This PR is to address the panic found in https://github.com/rust-lang/rust/issues/105700.
There are 2 separate things going on with this panic.
First the code could not generate a dummy response for crate fragment types when it hits the recursion limit.
This PR adds the method to the trait implementation for `DymmyResult` to be able to create a dummy crate node.
This stops the panic from happening.
The second thing that is not addressed (and maybe does not need addressing? 🤷🏻)
is that when you have multiple attributes it ends up treating attributes that follow another as being the result of expanding the former (maybe there is a better way to say that). So you end up hitting the recursion limit. Even though you would think there is no expansion happening here.
If you did not hit the recursion limit the compiler would output that `invalid_attribute` does not exists. But it currently exits before the resolution step when the recursion limit is reached here.
Type-directed probing for inherent associated types
When probing for inherent associated types (IATs), equate the Self-type found in the projection with the Self-type of the relevant inherent impl blocks and check if all predicates are satisfied.
Previously, we didn't look at the Self-type or at the bounds and just picked the first inherent impl block containing an associated type with the name we were searching for which is obviously incorrect.
Regarding the implementation, I basically copied what we do during method probing (`assemble_inherent_impl_probe`, `consider_probe`). Unfortunately, I had to duplicate a lot of the diagnostic code found in `rustc_hir_typeck::method::suggest` which we don't have access to in `rustc_hir_analysis`. Not sure if there is a simple way to unify the error handling. Note that in the future, `rustc_hir_analysis::astconv` might not actually be the place where we resolve inherent associated types (see https://github.com/rust-lang/rust/pull/103621#issuecomment-1304309565) but `rustc_hir_typeck` (?) in which case the duplication may naturally just disappear. While inherent associated *constants* are currently resolved during "method" probing, I did not find a straightforward way to incorporate IAT lookup into it as types and values (functions & constants) are two separate entities for which distinct code paths are taken.
Fixes#104251 (incl. https://github.com/rust-lang/rust/issues/104251#issuecomment-1338501171).
Fixes#105305.
Fixes#107468.
`@rustbot` label T-types F-inherent_associated_types
r? types
Make codegen choose whether to emit overflow checks
ConstProp and DataflowConstProp currently have a specific code path not to propagate constants when they overflow. This is meant to have the correct behaviour when inlining from a crate with overflow checks (like `core`) into a crate compiled without.
This PR shifts the behaviour change to the `Assert(Overflow*)` MIR terminators: if the crate is compiled without overflow checks, just skip emitting the assertions. This is already what happens with `OverflowNeg`.
This allows ConstProp and DataflowConstProp to transform `CheckedBinaryOp(Add, u8::MAX, 1)` into `const (0, true)`, and let codegen ignore the `true`.
The interpreter is modified to conform to this behaviour.
Fixes#35310
NB: Since we are using the same InferCtxt in each iteration,
we essentially *spoil* the inference variables and we only
ever get at most *one* applicable candidate (only the 1st candidate
has clean variables that can still unify correctly).
Fix RPITITs in default trait methods (by assuming projection predicates in param-env)
Instead of having special projection logic that allows us to turn `ProjectionTy(RPITIT, [Self#0, ...])` into `OpaqueTy(RPITIT, [Self#0, ...])`, we can instead augment the param-env of default trait method bodies to assume these as projection predicates. This should allow us to only project where we're allowed to!
In order to make this work without introducing a bunch of cycle errors, we additionally tweak the `OpaqueTypeExpander` used by `ParamEnv::with_reveal_all_normalized` to not normalize the right-hand side of projection predicates. This should be fine, because if we use the projection predicate to normalize some other projection type, we'll continue to normalize the opaque that it gets projected to.
This also makes it possible to support default trait methods with RPITITs in an associated-type based RPITIT lowering strategy without too much extra effort.
Fixes#107002
Alternative to #108142
Correctly handle links starting with whitespace
Part of https://github.com/rust-lang/rust/issues/107995.
I just got this issue, wrote a fix and then saw the issue. So here's the PR. ^^'
r? `@petrochenkov`
Rollup of 7 pull requests
Successful merges:
- #104659 (reflow the stack size story)
- #106933 (Update documentation of select_nth_unstable and select_nth_unstable_by to state O(n^2) complexity)
- #107783 (rustdoc: simplify DOM for `.item-table`)
- #107951 (resolve: Fix doc links referring to other crates when documenting proc macro crates directly)
- #108130 ("Basic usage" is redundant for there is just one example)
- #108146 (rustdoc: hide `reference` methods in search index)
- #108189 (Fix some more `non_lifetime_binders` stuff with higher-ranked trait bounds)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix some more `non_lifetime_binders` stuff with higher-ranked trait bounds
1. When assembling candidates for `for<T> T: Sized`, we can't ICE because the self-type is a bound type.
2. Fix an issue where, when canonicalizing in non-universe preserving mode, we don't actually set the universe for placeholders to the root even though we do the same for region vars.
3. Make `Placeholder("T")` format like `T` in error messages.
Fixes#108180Fixes#108182
r? types
Make `dyn*`'s value backend type a pointer
One tweak on top of Ralf's commit should fix using `usize` as a `dyn*`-coercible type, and should fix when we're using various other pointer types when LLVM opaque pointers is disabled.
r? `@eholk` but feel free to reassign
cc https://github.com/rust-lang/rust/pull/107728#issuecomment-1421231823 `@RalfJung`
Check that built-in callable types validate their output type is `Sized` (in new solver)
Working on parity with old solver. Putting this up for consideration, it's not *really* needed or anything just yet. Maybe it's better to approach this from another direction (like always checking the item bounds when calling `consider_assumption`? we may need that for coinduction to be sound though?)
This basically implements #100096 for the new solver.
Don't call `with_reveal_all_normalized` in const-eval when `param_env` has inference vars in it
**what:** This slightly shifts the order of operations from an existing hack:
5b6ed253c4/compiler/rustc_middle/src/ty/consts/kind.rs (L225-L230)
in order to avoid calling a tcx query (`TyCtxt::reveal_opaque_types_in_bounds`, via `ParamEnv::with_reveal_all_normalized`) when a param-env has inference variables in it.
**why:** This allows us to enable fingerprinting of query keys/values outside of incr-comp in deubg mode, to make sure we catch other places where we're passing infer vars and other bad things into query keys. Currently that (bbf33836b9) crashes because we introduce inference vars into a param-env in the blanket-impl finder in rustdoc 😓5b6ed253c4/src/librustdoc/clean/blanket_impl.rs (L43)
See the CI failure here: https://github.com/rust-lang/rust/actions/runs/4058194838/jobs/6984834619
Deny non-lifetime bound vars in `for<..> ||` closure binders
Moves the check for illegal bound var types from astconv to resolve_bound_vars. If a binder is defined to have a type or const late-bound var that's not allowed, we'll resolve any usages to ty error or const error values, so we shouldn't ever see late-bound types or consts in places they aren't expected.
Fixes#108184Fixes#108181Fixes#108192
Don't eagerly convert principal to string
Fixes#108155
~~I haven't yet been able to reproduce the ICE in a minimal example unfortunately.~~ Added a test
Don't allow evaluating queries that were fed in a previous compiler run
r? `@cjgillot`
this code was already unreachable. Also we removed the no_hash + feeding restriction in https://github.com/rust-lang/rust/pull/105220.
Don't recover lifetimes/labels containing emojis as character literals
Fixes#108019.
Note that at the time of this commit, `unic-emoji-char` seems to have data tables only up to Unicode 5.0, but Unicode is already newer than this.
A newer emoji such as `🥺` will not be recognized as an emoji but older emojis such as `🐱` will.
This PR leaves a couple of FIXMEs where `unic_emoji_char::is_emoji` is used.
Add sanitizer support for modern iOS platforms
asan and tsan generally support iOS, but that previously wasn't configured in rust. This only adds support for the simulator architectures, and arm64 device architecture, not the older 32 bit architectures.
Add `kernel-address` sanitizer support for freestanding targets
This PR adds support for KASan (kernel address sanitizer) instrumentation in freestanding targets. I included the minimal set of `x86_64-unknown-none`, `riscv64{imac, gc}-unknown-none-elf`, and `aarch64-unknown-none` but there's likely other targets it can be added to. (`linux_kernel_base.rs`?) KASan uses the address sanitizer attributes but has the `CompileKernel` parameter set to `true` in the pass creation.
Enable instcombine for mutable reborrows
`instcombine` used to contain this comment, which is no longer accurate because there it is fine to copy `&mut _` in MIR:
```rust
// The dereferenced place must have type `&_`, so that we don't copy `&mut _`.
```
So let's try replacing that check with something much more permissive...
Default `repr(C)` enums to `c_int` size
This is what ISO C strongly implies this is correct, and
many processor-specific ABIs imply or mandate this size, so
"everyone" (LLVM, gcc...) defaults to emitting enums this way.
However, this is by no means guaranteed by ISO C,
and the bare-metal Arm targets show it can be overridden,
which rustc supports via `c-enum-min-bits` in a target.json.
The override is a flag named `-fshort-enums` in clang and gcc,
but introducing a CLI flag is probably unnecessary for rustc.
This flag can be used by non-Arm microcontroller targets,
like AVR and MSP430, but it is not enabled for them by default.
Rust programmers who know the size of a target's enums
can use explicit reprs, which also lets them match C23 code.
This change is most relevant to 16-bit targets: AVR and MSP430.
Most of rustc's targets use 32-bit ints, but ILP64 does exist.
Regardless, rustc should now correctly handle enums for
both very small and very large targets.
Thanks to William for confirming MSP430 behavior,
and to Waffle for better style and no-core `size_of` asserts.
Fixesrust-lang/rust#107361Fixesrust-lang/rust#77806
Add `Clause::ConstArgHasType`
Currently the way that we check that a const arg has the correct type for the const param it is an argument for is by setting the expected type of `typeck` on the anon const of the argument to be the const param's type.
In the future for a potential `min_generic_const_exprs` we will allow providing const arguments that do not have an associated anon const that can be typeck'd which will require us to actually check that the const argument has the correct type. While it would potentially be possible to just call `eq` when creating substs this would not work if we support generics of the form `const N: T, T` (the const parameters type referencing generics declared after itself).
Additionally having `ConstArgHasType` will allow us to potentially make progress on removing the `ty` field of `Const` which may be desirable. Once progress has been made on this, `ConstArgHasType` will also be helpful in ensuring we do not make mistakes in trait/impl checking by declaring functions with the wrong const parameter types as the checks that the param env is compatible would catch it. (We have messed this up in the past, and with generic const parameter types these checks will get more complex)
There is a [document](https://hackmd.io/wuCS6CJBQ9-fWbwaW7nQRw?view) about the types of const generics that may provide some general information on this subject
---
This PR shouldn't have any impact on whether code compiles or not on stable, it primarily exists to make progress on unstable const generics features that are desirable.
This function has this line twice:
```
let bound_vars = tcx.intern_bound_variable_kinds(&bound_vars);
```
The second occurrence is effectively a no-op, because the first
occurrence interned any that needed it.
There are two traits, `InternAs` and `InternIteratorElement`. I found
them confusing to use, particularly this:
```
pub fn mk_tup<I: InternAs<Ty<'tcx>, Ty<'tcx>>>(self, iter: I) -> I::Output {
iter.intern_with(|ts| self.intern_tup(ts))
}
```
where I thought there might have been two levels of interning going on
(there isn't) due to the `intern_with`/`InternAs` + `intern_tup` naming.
And then I found the actual traits and impls themselves *very*
confusing.
- `InternAs` has a single impl, for iterators, with four type variables.
- `InternAs` is only implemented for iterators because it wouldn't
really make sense to implement for any other type. And you can't
really understand the trait without seeing that single impl, which is
suspicious.
- `InternAs` is basically just a wrapper for `InternIteratorElement`
which does all the actual work.
- Neither trait actually does any interning. They just have `Intern` in
their name because they are used *by* interning code.
- There are no comments.
So this commit improves things.
- It removes `InternAs` completely. This makes the `mk_*` function
signatures slightly more verbose -- two trait bounds instead of one --
but much easier to read, because you only need to understand one trait
instead of two.
- It renames `InternIteratorElement` as `CollectAndApply`. Likewise, it
renames its method `intern_with` as `collect_and_apply`. These names
describe better what's going on: we collect the iterator elements into
a slice and then apply a function to the slice.
- It adds comments, making clear that all this is all there just to
provide an optimized version of `f(&iter.collect::<Vec<_>>())`.
It took me a couple of attempts to come up with this commit. My initial
attempt kept `InternAs` around, but renamed things and added comments,
and I wasn't happy with it. I think this version is much better. The
resulting code is shorter, despite the addition of the comments.
`InternIteratorElement` is a trait used to intern values produces by
iterators. There are three impls, corresponding to iterators that
produce different types:
- One for `T`, which operates straightforwardly.
- One for `Result<T, E>`, which is fallible, and will fail early with an
error result if any of the iterator elements are errors.
- One for `&'a T`, which clones the items as it iterates.
That last one is bad: it's extremely easy to use it without realizing
that it clones, which goes against Rust's normal "explicit is better"
approach to cloning.
So this commit just removes it. In practice, there weren't many use
sites. For all but one of them `into_iter()` could be used, which avoids
the need for cloning. And for the one remaining case `copied()` is
used.
There are several `mk_foo`/`intern_foo` pairs, where the former takes an
iterator and the latter takes a slice. (This naming convention is bad,
but that's a fix for another PR.)
This commit changes several `mk_foo` occurrences into `intern_foo`,
avoiding the need for some `.iter()`/`.into_iter()` calls. Affected
cases:
- mk_type_list
- mk_tup
- mk_substs
- mk_const_list
Switch to `EarlyBinder` for `type_of` query
Part of the work to finish #105779 and implement https://github.com/rust-lang/types-team/issues/78.
Several queries `X` have a `bound_X` variant that wraps the output in `EarlyBinder`. This adds `EarlyBinder` to the return type of the `type_of` query and removes `bound_type_of`.
r? `@lcnr`
Do not ICE on unmet trait alias impl bounds
Fixes#108132
I've also added some documentation to the `impl_def_id` field of `DerivedObligationCause` to try and minimise the risk of such errors in future.
r? `@compiler-errors`
wasm: Register the `relaxed-simd` target feature
This WebAssembly proposal is likely to reach stage 4 soon so this starts the support in Rust for the proposal by adding a target feature that can be enabled via attributes for the stdarch project to bind the intrinsics.
Implement partial support for non-lifetime binders
This implements support for non-lifetime binders. It's pretty useless currently, but I wanted to put this up so the implementation can be discussed.
Specifically, this piggybacks off of the late-bound lifetime collection code in `rustc_hir_typeck::collect::lifetimes`. This seems like a necessary step given the fact we don't resolve late-bound regions until this point, and binders are sometimes merged.
Q: I'm not sure if I should go along this route, or try to modify the earlier nameres code to compute the right bound var indices for type and const binders eagerly... If so, I'll need to rename all these queries to something more appropriate (I've done this for `resolve_lifetime::Region` -> `resolve_lifetime::ResolvedArg`)
cc rust-lang/types-team#81
r? `@ghost`
This is what ISO C strongly implies this is correct, and
many processor-specific ABIs imply or mandate this size, so
"everyone" (LLVM, gcc...) defaults to emitting enums this way.
However, this is by no means guaranteed by ISO C,
and the bare-metal Arm targets show it can be overridden,
which rustc supports via `c-enum-min-bits` in a target.json.
The override is a flag named `-fshort-enums` in clang and gcc,
but introducing a CLI flag is probably unnecessary for rustc.
This flag can be used by non-Arm microcontroller targets,
like AVR and MSP430, but it is not enabled for them by default.
Rust programmers who know the size of a target's enums
can use explicit reprs, which also lets them match C23 code.
This change is most relevant to 16-bit targets: AVR and MSP430.
Most of rustc's targets use 32-bit ints, but ILP64 does exist.
Regardless, rustc should now correctly handle enums for
both very small and very large targets.
Thanks to William for confirming MSP430 behavior,
and to Waffle for better style and no-core size_of asserts.
Co-authored-by: William D. Jones <thor0505@comcast.net>
Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
Factor query arena allocation out from query caches
This moves the logic for arena allocation out from the query caches into conditional code in the query system. The specialized arena caches are removed. A new `QuerySystem` type is added in `rustc_middle` which contains the arenas, providers and query caches.
Performance seems to be slightly regressed:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.8053s</td><td align="right">1.8109s</td><td align="right"> 0.31%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2600s</td><td align="right">0.2597s</td><td align="right"> -0.10%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9973s</td><td align="right">1.0006s</td><td align="right"> 0.34%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.6048s</td><td align="right">1.6051s</td><td align="right"> 0.02%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">6.2992s</td><td align="right">6.3159s</td><td align="right"> 0.26%</td></tr><tr><td>Total</td><td align="right">10.9664s</td><td align="right">10.9922s</td><td align="right"> 0.23%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">1.0017s</td><td align="right"> 0.17%</td></tr></table>
Incremental performance is a bit worse:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check:initial</td><td align="right">2.2103s</td><td align="right">2.2247s</td><td align="right"> 0.65%</td></tr><tr><td>🟣 <b>hyper</b>:check:initial</td><td align="right">0.3335s</td><td align="right">0.3349s</td><td align="right"> 0.41%</td></tr><tr><td>🟣 <b>regex</b>:check:initial</td><td align="right">1.2597s</td><td align="right">1.2650s</td><td align="right"> 0.42%</td></tr><tr><td>🟣 <b>syn</b>:check:initial</td><td align="right">2.0521s</td><td align="right">2.0613s</td><td align="right"> 0.45%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:initial</td><td align="right">7.8275s</td><td align="right">7.8583s</td><td align="right"> 0.39%</td></tr><tr><td>Total</td><td align="right">13.6832s</td><td align="right">13.7442s</td><td align="right"> 0.45%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">1.0046s</td><td align="right"> 0.46%</td></tr></table>
It does seem like LLVM optimizers struggle a bit with the current state of the query system.
Based on top of https://github.com/rust-lang/rust/pull/107782 and https://github.com/rust-lang/rust/pull/107802.
r? `@cjgillot`
Rollup of 7 pull requests
Successful merges:
- #106347 (More accurate spans for arg removal suggestion)
- #108057 (Prevent some attributes from being merged with others on reexports)
- #108090 (`if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)`)
- #108092 (note issue for feature(packed_bundled_libs))
- #108099 (use chars instead of strings where applicable)
- #108115 (Do not ICE on unmet trait alias bounds)
- #108125 (Add new people to the compiletest review rotation)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Optimize `mk_region`
PR #107869 avoiding some interning under `mk_ty` by special-casing `Ty` variants with simple (integer) bodies. This PR does something similar for regions.
r? `@compiler-errors`
