This means that things like `<usize as Step>::forward_unchecked` and `<PartialOrd for f32>::le` will inline even if we've already done a bunch of inlining to find the calls to them.
Do not register `Self: AutoTrait` when confirming auto trait (in old solver)
Every built-in auto impl for a trait goal like `Ty: Auto` immediately registers another obligation of `Ty: Auto` as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a `Self: Trait` predicate.
To fix this, remove the call to `impl_or_trait_obligations` in `vtable_auto_impl`, since auto traits do not have where clauses.
r? lcnr
In LLVM v9, lld has supported @response-file
LLVM v9 was released on 2019-09-19.
And the check was added back to 2018-03-14 (1.26.0) via 04442af18b.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <bb12396f91>
* <https://reviews.llvm.org/D63024>
Calculate predecessor count directly
Avoid allocating a vector of small vectors merely to determine how many
predecessors each basic block has.
Additionally use u8 and saturating operations. The pass only needs to
distinguish between [0..1] and [2..].
Alot of the current id handling is weird and unnecessary. e.g:
1. The fully uninterned id type was (FullItemId, Option<FullItemId>)
meaning it wasn't actually full!
2. None of the extra fields in Option<FullItemId> would ever be used
3. imported_item_id was a rustdoc_json_types::Id instead of a simpler
DefId
This commit removes the unnessessary complexity, and documents where the
remaining complexity comes from.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
The targets used the plain `$ARCH` triple, which LLVM normalizes to
`$ARCH-unknown-unknown`, which is inconsistent with the the other
VxWorks targets which all use `$ARCH-unknown-linux-gnu$ABI`.
I want to work on this in a followup commit, so in this commit I make it
self-contained. Contains no code changes, all functions are defined
exactly as they were in conversions.rs.
This is more useful than `allow` as compiler will force us to remove rules
that are no longer valid (we already got 2 of them in this change).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Use sa_sigaction instead of sa_union.__su_sigaction for AIX
Revert test cases to use `sa_sigaction` instead of `sa_union.__su_sigaction`, now that the `libc` crate implementation for AIX defines `sa_sigaction` as a direct member of `struct sigaction`, aligning it with implementations on other similar platforms. ([[AIX] Use sa_sigaction instead of the union](https://github.com/rust-lang/libc/pull/4250)).
Rustdoc: remove a bunch of @ts-expect-error from main.js
r? ```````@notriddle```````
Most remaining instances of ````````@ts-expect-error```````` in `search.js` and `main.js` are some sort of unchecked assertion, most of them involving nullibility, and we have yet to decide on how to handle these.
Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs
In #137617, the `ConstParamTy` rib was adjusted to act kinda like the `ForwardGenericParamBan`. However, this means that it no longer served its purpose banning generics from *parent items*. Although we still are checking for param type validity using the `ConstParamTy_` trait, which means that we weren't accepting code we shouldn't, I think it's a bit strange for us not to be rejecting code like this during *resolution* and instead letting these malformed const generics leak into the type system:
```rust
trait Foo<T> {
fn bar<const N: T>() {}
}
```
This PR does a few things:
1. Introduce a `ForwardGenericParamBanReason` enum, and start using the `ForwardGenericParamBan` rib to ban forward-declared params in const tys when `generic_const_parameter_types` is enabled.
2. Start using the `ConstParamTy` rib to ban *all* generics when `generic_const_parameter_types` is disabled.
3. Improve the diagnostics for both of the cases above, and for forward-declared params in parameter defaults too :3
r? `@BoxyUwU` or reassign
Support rmeta inputs for --crate-type=bin --emit=obj
This already works for --emit=metadata, but is possible anytime we're not linking.
Tests:
- `rmeta_bin` checks we're not changing --emit=link (already passes)
- `rmeta_bin-pass` tests the new behavior for --emit=obj (would fail today) and also --emit=metadata which isn't changing
uefi: fs: Implement FileType, FilePermissions and FileAttr
- In UEFI, both FileType and FilePermissions are represented by the attr bitfield.
- Using simple bools here since both are represented by a single bit.
- Add `FILE_PERMISSION` mask for constructing attribute while change permissions.
cc ````@nicholasbishop````
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````````
