Refactor C FFI variadics to more closely match their C counterparts, and add Clone implementation
We had to make some changes to expose `va_copy` and `va_end` directly to users (mainly for C2Rust, but not exclusively):
- redefine the Rust variadic structures to more closely correspond to C: `VaList` now matches `va_list`, and `VaListImpl` matches `__va_list_tag`
- add `Clone` for `VaListImpl`
- add explicit `as_va_list()` conversion function from `VaListImpl` to `VaList`
- add deref coercion from `VaList` to `VaListImpl`
- add support for the `asmjs` target
All these changes were needed for use cases like:
```Rust
let mut ap2 = va_copy(ap);
vprintf(fmt, ap2);
va_end(&mut ap2);
```
rustc: remove 'x: 'y bounds (except where necessary or from comments/strings).
This PR removes all lifetime-lifetime "outlives" bounds (e.g. `'tcx: 'a`) bounds except a few necessary ones (see the `reintroduce lifetime bounds where necessary` commit).
Some of these bounds kept around otherwise-unused lifetimes (e.g. `<'a, 'tcx: 'a>` followed by uses of `'tcx` but not `'a`) - these lifetimes (i.e. `'a`) were then removed.
(maybe they should be considered unused by the lint? cc @matthewjasper @zackmdavis)
r? @oli-obk cc @rust-lang/compiler
Make use of `ptr::null(_mut)` instead of casting zero
There are few places that I don't replace the zero casting pointer with `ptr::null`
or `ptr::null_mut`:
```bash
% git grep -E '[ ([{]0 as \*'
src/libcore/ptr/mod.rs:216:pub const fn null<T>() -> *const T { 0 as *const T }
src/libcore/ptr/mod.rs:231:pub const fn null_mut<T>() -> *mut T { 0 as *mut T }
src/test/run-pass/consts/const-cast-ptr-int.rs:12:static a: TestStruct = TestStruct{x: 0 as *const u8};
src/test/ui/issues/issue-45730.rs:5: let x: *const _ = 0 as *const _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.rs:8: let x = 0 as *const i32 as *const _ as *mut _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.stderr:14:LL | let x: *const _ = 0 as *const _;
src/test/ui/issues/issue-45730.stderr:24:LL | let x = 0 as *const i32 as *const _ as *mut _;
src/test/ui/lint/lint-forbid-internal-unsafe.rs:15: println!("{}", evil!(*(0 as *const u8)));
src/test/ui/order-dependent-cast-inference.rs:5: let mut y = 0 as *const _;
src/test/ui/order-dependent-cast-inference.stderr:4:LL | let mut y = 0 as *const _;
```
r? @sfackler
don't ICE on large files
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
closes#61904
r? @petrochenkov
make `Weak::ptr_eq`s into methods
This makes the `Weak::ptr_eq`s associated function into methods. There's no reason for methods on `Weak`s to be associated functions, as there is no `Dered` thus no possibility of a collision. Also: methods can be called using the associated function syntax.
follow up on https://github.com/rust-lang/rust/pull/55987
[Tracking issue for weak_ptr_eq](https://github.com/rust-lang/rust/issues/55981)
Help LLVM better optimize slice::Iter(Mut)::len
r? @RalfJung
I've included a codegen test that fails without this change as a demonstration of usefulness.
Replace some uses of NodeId with HirId
We are still using `NodeId` in some spots where we could use `HirId` instead; this PR targets some of these spots and removes some of the associated `hir::map` functions.
test more variants of enum-int-casting
As I learned in https://github.com/rust-lang/rust/pull/61673#issuecomment-500213506, there is a code path we are not testing yet. Looks like enum-int-casting with and without an intermediate let-binding is totally different.
EDIT: The reason for this is to get rid of the cycle in definitions such as:
```rust
enum Foo {
A = 0,
B = Foo::A as isize + 2,
}
```
This has historically been supported, so a hack adding special treatment to `Enum::Variant as _` was added to keep supporting it.
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
typeck: extract expr type-checking to expr.rs + refactor check_expr_kind
In this PR we:
- Extract out the bulk of the expression type checking logic from `check/mod.rs` into a new file `check/expr.rs`.
- Refactor `fn check_expr_kind` into several smaller functions.
More functions should probably be moved but I think this is a reasonable start.
r? @oli-obk
cc @eddyb
submodules: update clippy from 7b2a7a22 to be5d17fe
Changes:
````
Fix wrong lifetime of TyCtxt
Use replace_region_in_file for creating the lint list
Restructure rename tests
Register rename to the LintStore.
Rename REDUNDANT_STATIC_LIFETIME to REDUNDANT_STATIC_LIFETIMES.
Remove pub from RedundantStaticLifetime.visit_type function.
Rename const_static_lifetime to redundant_static_lifetime.
Merge StaticConst and StaticStatic lints into StaticConst.
Use RedundantStaticLifetime in StaticStatic.
Move type-checking logic in StaticConst to RedundantStaticLifetime.
Add lint for statics with explicit static lifetime.
minor fix
make it pass dogfood
run rustfmt
fix padding and put clippy someplaces
show default lint levels
group printing
prelim arg parse
move Lint static def into its own module
switch to sorted usable lints
Update clippy_dev/src/main.rs
initial commit for help improvements on clippy-driver
````
Fixes clippy toolstate.
r? @oli-obk
weird-exprs: if if if if
The `if` keyword can be chained as long as there are enough `{...} else {...}` following, and they all return a `bool` (not required for the last one).
`if` expression can be also put inside a `match` arm guard, thus making the whole thing a little bit more confusing.
Discovered this clusterfunk while reading the reference because I have nothing better to do.
librustc_codegen_llvm: Use repr(transparent) for bitflags over repr(C…
…) (#61306)
In order to make sure that Rust's bitflags types are passed the same way in the Rust ABI as they are in the C ABI, we need to use the attribute repr(transparent) over the repr(C) attribute for the single-field bitflags structs in in order to prevent ABI mismatches. Thanks to Michael Karcher for finding this bug.
create a "provisional cache" to restore performance in the case of cycles
Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.
Caveat: I've not run `x.py test` in full yet.
r? @pnkfelix
cc @arielb1
Fixes#60846
Separate unit tests
I'm working on #61097.
About half of the modules are done but dozens of modules are still remaining. I will rebase and squash the commits later.
