Currently (PatKind::Wild` (i.e. `_`) gets turned by
`lower_fn_params_to_names` into an empty identifier, which means it is
printed incorrectly by HIR pretty printing.
And likewise for `lower_fn_params_to_names`, which affects some error
messages.
This commit fixes them. This requires a slight tweak in a couple of
places to continue using parameter numbers in some error messages. And
it improves the output of `tests/ui/typeck/cyclic_type_ice.rs`:
`/* _ */` is a better suggestion than `/* */`.
Convert `ShardedHashMap` to use `hashbrown::HashTable`
The `hash_raw_entry` feature (#56167) has finished fcp-close, so the compiler
should stop using it to allow its removal. Several `Sharded` maps were
using raw entries to avoid re-hashing between shard and map lookup, and
we can do that with `hashbrown::HashTable` instead.
change definitely unproductive cycles to error
builds on top of #136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits.
With this, we can change cycles which are definitely unproductive to a proper error. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/114. This does not affect stable as we keep these cycles as ambiguous during coherence.
r? ````````@compiler-errors```````` ````````@nikomatsakis````````
Fix false-positive in `expr_or_init` and in the `invalid_from_utf8` lint
This PR fixes the logic for finding initializer in the `expr_or_init` and `expr_or_init_with_outside_body` functions.
If the binding were to be mutable (`let mut`), the logic wouldn't consider that the initializer expression could have been modified and would return the init expression even-trough multiple subsequent assignments could have been done.
Example:
```rust
let mut a = [99, 108, 130, 105, 112, 112]; // invalid, not UTF-8
loop {
a = *b"clippy"; // valid
break;
}
std::str::from_utf8_mut(&mut a); // currently warns, with this PR it doesn't
```
This PR modifies the logic to excludes mutable let bindings.
Found when using `expr_or_init` in https://github.com/rust-lang/rust/pull/119220.
r? compiler
Elaborate trait assumption in `receiver_is_dispatchable`
Fixes#138172. See comment on the linked test.
Probably not a fix for the general problem, bc I think this may still be incomplete for other weird `where` clauses on the receiver. But 🤷, supertraits seems like an obvious one to fix.
Allow bounds checks when enumerating `IndexSlice` to be elided
Without this hint, each loop iteration has to separately bounds check the index. See https://godbolt.org/z/zrfPY4Ten for an example.
This is technically a behaviour change, but only in cases where the compiler is going to crash anyways.
The idea is to identify cases of symbols/identifiers that are not
expected to be used. There isn't a perfectly sharp line between "dummy"
and "not dummy", but I think it's useful nonetheless.
This is never hit in the test suite.
At some point the check should be removed entirely. There are a million
places in the compiler where an empty symbol doesn't make sense, so a
check of this nature has almost zero value. But I'll leave it in place
for now just in case it gets hit by fuzzing or in the wild.
Rollup of 10 pull requests
Successful merges:
- #137715 (Allow int literals for pattern types with int base types)
- #138002 (Disable CFI for weakly linked syscalls)
- #138051 (Add support for downloading GCC from CI)
- #138231 (Prevent ICE in autodiff validation by emitting user-friendly errors)
- #138245 (stabilize `ci_rustc_if_unchanged_logic` test for local environments)
- #138256 (Do not feed anon const a type that references generics that it does not have)
- #138284 (Do not write user type annotation for const param value path)
- #138296 (Remove `AdtFlags::IS_ANONYMOUS` and `Copy`/`Clone` condition for anonymous ADT)
- #138352 (miri native_calls: ensure we actually expose *mutable* provenance to the memory FFI can access)
- #138354 (remove redundant `body` arguments)
r? `@ghost`
`@rustbot` modify labels: rollup
miri native_calls: ensure we actually expose *mutable* provenance to the memory FFI can access
In native call mode, the interpreter memory itself is accessed directly by external code via pointers created from integers and passed via libffi, so we have to ensure the provenance in Miri itself (on the meta level) is sufficiently exposed. So far we only exposed the provenance for read-only accesses. This may we enough as that may actually be the same provenance as for mutable accesses, but it's hard to be sure, and anyway there's no reason to do such a gambit -- we have this function, `prepare_for_native_call`, which iterates all memory the call can access. let's just also (re-)expose Miri's own allocations there. We expose the read-only provenance for all of them and the mutable provenance for the mutable allocations.
r? ``@oli-obk``
Remove `AdtFlags::IS_ANONYMOUS` and `Copy`/`Clone` condition for anonymous ADT
cc #131045, which removed anonymous ADTs from the compiler
I forgot more stuff I guess.
Do not write user type annotation for const param value path
As I noted in the code comment, `DefKind::ConstParam` isn't actually *generic* over its own args, we just use the identity args from the body when lowering the value path so we have something to plug into the `EarlyBinder` we get back from `type_of` for the const param. So skip over it in `write_user_type_annotation_from_args`.
Somewhat unrelated, but I left an explanation for a somewhat mysterious quirk in the THIR lowering of user type annotations for patterns having to do with ctors and their `type_of` not actually being the type of the pattern node it's ascribing.
Fixes#138048
r? ``@BoxyUwU``
Do not feed anon const a type that references generics that it does not have
Fixes#137865
See the comment I left in the code. We could alternatively give these anon consts the generics from the parent, but that would be moving in a GCE-esque direction that we may not want. Open to tweaks here.
r? BoxyUwU
Prevent ICE in autodiff validation by emitting user-friendly errors
This PR moves `valid_ret_activity` and `valid_input_activity` checks to the macro expansion phase in compiler/rustc_builtin_macros/src/autodiff.rs, replacing the following internal compiler error (ICE):
```
error: internal compiler error:
compiler/rustc_codegen_ssa/src/codegen_attrs.rs:935:13:
Invalid input activity Dual for Reverse mode
```
with a more user-friendly message.
The issue specifically affected the test file `tests/ui/autodiff/autodiff_illegal.rs`, impacting the functions `f5` and `f6`.
The ICE can be reproduced by following [Enzyme's Rustbook](https://enzymead.github.io/rustbook/installation.html) installation guide.
Additionally, this PR adds tests for invalid return activity in `autodiff_illegal.rs`, which previously triggered an unnoticed ICE before these fixes.
r? ``@oli-obk``
Allow int literals for pattern types with int base types
r? ``@BoxyUwU``
I also added an error at layout computation time for layouts that contain wrapping ranges (happens at monomorphization time). This is obviously hacky, but at least prevents such types from making it to codegen for now. It made writing the tests for int literals easier as I didn't have to think about that edge case
Basically this PR allows you to stop using transmutes for creating pattern types and instead just use literals:
```rust
let x: pattern_type!(u32 is 5..10) = 7;
```
works, and if the literal is out of range you get a type mismatch because it just stays at the base type and the base type can't be coerced to the pattern type.
cc ``@joshtriplett`` ``@scottmcm``
Add `#[define_opaques]` attribute and require it for all type-alias-impl-trait sites that register a hidden type
Instead of relying on the signature of items to decide whether they are constraining an opaque type, the opaque types that the item constrains must be explicitly listed.
A previous version of this PR used an actual attribute, but had to keep the resolved `DefId`s in a side table.
Now we just lower to fields in the AST that have no surface syntax, instead a builtin attribute macro fills in those fields where applicable.
Note that for convenience referencing opaque types in associated types from associated methods on the same impl will not require an attribute. If that causes problems `#[defines()]` can be used to overwrite the default of searching for opaques in the signature.
One wart of this design is that closures and static items do not have generics. So since I stored the opaques in the generics of functions, consts and methods, I would need to add a custom field to closures and statics to track this information. During a T-types discussion we decided to just not do this for now.
fixes#131298
Remove unnecessary `[lints.rust]` sections.
`bootstrap` and `llvm_enzyme` are now both in the extra `check-cfg` list in bootstrap, so they doesn't need to be handled explicitly in `Cargo.toml` files.
r? ```@jieyouxu```
Improve `-Zunpretty=hir` for parsed attrs
0. Rename `print_something` to `should_render` to make it distinct from `print_attribute` in that it doesn't print anything, it's just a way to probe if a type renders anything.
1. Fixes a few bugs in the `PrintAttribute` derive. Namely, the `__printed_anything` variable was entangled with the `should_render` call, leading us to always render field names but never render commas.
2. Remove the outermost `""` from the attr.
3. Debug print `Symbol`s. I know that this is redundant for some parsed attributes, but there's no good way to distinguish symbols that are ident-like and symbols which are cooked string literals. We could perhaps *conditionally* to fall back to a debug printing if the symbol doesn't match an ident? But seems like overkill.
Based on #138060, only review the commits not in that one.
Speed up target feature computation
The LLVM backend calls `LLVMRustHasFeature` twice for every feature. In short-running rustc invocations, this accounts for a surprising amount of work.
r? `@bjorn3`
