| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 7 pull requests
Successful merges:
- #137314 (change definitely unproductive cycles to error)
- #137701 (Convert `ShardedHashMap` to use `hashbrown::HashTable`)
- #138269 (uefi: fs: Implement FileType, FilePermissions and FileAttr)
- #138331 (Use `RUSTC_LINT_FLAGS` more)
- #138345 (Some autodiff cleanups)
- #138387 (intrinsics: remove unnecessary leading underscore from argument names)
- #138390 (fix incorrect tracing log)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Delegation: reject C-variadics
The explanation is contained in attached issues.
Fixes https://github.com/rust-lang/rust/issues/127443
Fixes https://github.com/rust-lang/rust/issues/127413
r? `@petrochenkov`
|
|
Delegation: one more ICE fix for `MethodCall` generation
self-explanatory
Fixes https://github.com/rust-lang/rust/issues/138362
r? `@petrochenkov`
|
|
remove unnecessary variant
|
|
merge `TypeChecker` and `TypeVerifier`
Stacked on top of #138354. Best reviewed commit by commit.
r? `@compiler-errors`
|
|
r=onur-ozkan,jieyouxu
Use `RUSTC_LINT_FLAGS` more
An alternative to the failed #138084.
Fixes #138106.
r? `````@jieyouxu`````
|
|
fix ICE in pretty-printing `global_asm!`
fixes https://github.com/rust-lang/rust/issues/138260
since https://github.com/rust-lang/rust/pull/137180, `global_asm!` gets a fake body, that the pretty printing logic did not know what to do with.
based on [#t-compiler/help > tests for MIR pretty printing](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tests.20for.20MIR.20pretty.20printing) I created `tests/ui/unpretty/mir` which seemed as good a place as any for a test. If there is a better place, let me know.
try-job: test-various
try-job: x86_64-apple-2
|
|
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
|
|
Move methods from Map to TyCtxt, part 4.
A follow-up to https://github.com/rust-lang/rust/pull/137350.
r? ```@Zalathar```
|
|
intrinsics: remove unnecessary leading underscore from argument names
This is unnecessary since https://github.com/rust-lang/rust/pull/135840.
|
|
Some autodiff cleanups
cc ````@ZuseZ4````
just some things I noticed
|
|
r=onur-ozkan,jieyouxu
Use `RUSTC_LINT_FLAGS` more
An alternative to the failed #138084.
Fixes #138106.
r? ````@jieyouxu````
|
|
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````````
|
|
|
|
|
|
|
|
|
|
All callers unwrap the result.
|
|
|
|
build_session_options always uses materialize_sysroot anyway.
|
|
|
|
|
|
|
|
|
|
Remove `NtItem` and `NtStmt`
Another piece of #124141.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
Today we're making LLVM do a bunch of extra work for every enum you match on, even trivial stuff like `Option<bool>`. Let's not.
|
|
Remove unnecessary lifetime from `PatInfo`.
r? ```@jackh726```
|
|
r=compiler-errors
Item-related cleanups
I have been looking at `hir::Item` closely and found a few minor cleanup opportunities.
r? ```@spastorino```
|
|
Refactor `pick2_mut` & `pick3_mut` to use `get_disjoint_mut`
Closes #138196
|
|
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
|
|
Reduce `kw::Empty` usage, part 2
A few small `kw::Empty` removals, or steps toward removals.
r? fmease
|
|
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.
|
|
|
|
It has a single call site. The removal of the closure argument is a nice
touch.
|
|
|
|
The list of `ASM_SUPPORTED_ARCHS` was missing a few from the compiler's
actual stable list.
|
|
|
|
`adjust_ident_and_get_scope` returns the symbol it receives unchanged,
and the call site ignores the returned symbol, so this symbol is unused.
|
|
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.
|
|
Replace it with an assert for now, just in case it is reachable.
|
|
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.
|
|
Continuing the work from #137350.
Removes the unused methods: `expect_variant`, `expect_field`,
`expect_foreign_item`.
Every method gains a `hir_` prefix.
|
