Allow projections to be promoted to constants in MIR.
This employs the `LvalueContext` additions by @pcwalton to properly extend the MIR promotion of temporaries to allow projections (field accesses, indexing and dereferences) on said temporaries.
It's needed both parity with the old constant qualification logic (for current borrowck) and it fixes#38074.
The former is *required for soundness* if we accept the RFC for promoting rvalues to `'static` constants.
That is, until we get MIR borrowck and the same source of truth will be used for both checks and codegen.
[11/n] Separate ty::Tables into one per each body.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/38449) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
In order to track the results of type-checking and inference for incremental recompilation, they must be stored separately for each function or constant value, instead of lumped together.
These side-`Tables` also have to be tracked by various passes, as they visit through bodies (all of which have `Tables`, even if closures share the ones from their parent functions). This is usually done by switching a `tables` field in an override of `visit_nested_body` before recursing through `visit_body`, to the relevant one and then restoring it - however, in many cases the nesting is unnecessary and creating the visitor for each body in the crate and then visiting that body, would be a much cleaner solution.
To simplify handling of inlined HIR & its side-tables, their `NodeId` remapping and entries HIR map were fully stripped out, which means that `NodeId`s from inlined HIR must not be used where a local `NodeId` is expected. It might be possible to make the nodes (`Expr`, `Block`, `Pat`, etc.) that only show up within a `Body` have IDs that are scoped to that `Body`, which would also allow `Tables` to use `Vec`s.
That last part also fixes#38790 which was accidentally introduced in a previous refactor.
E0088/E0090 fix
This fixes an issue reported by @eddyb (https://github.com/rust-lang/rust/pull/36208#issuecomment-2707092230) where the check for "too few lifetime parameters" was removed in one of the error message PRs.
I also removed the span shrinking from E0088, as early bound lifetimes give you a confusing underline in some cases.
r=eddyb
std: Don't pass overlapped handles to processes
This commit fixes a mistake introduced in #31618 where overlapped handles were
leaked to child processes on Windows. On Windows once a handle is in overlapped
mode it should always have I/O executed with an instance of `OVERLAPPED`. Most
child processes, however, are not prepared to have their stdio handles in
overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle.
Now we haven't had any odd behavior in Rust up to this point, and the original
bug was introduced almost a year ago. I believe this is because it turns out
that if you *don't* pass an `OVERLAPPED` then the system will [supply one for
you][link]. In this case everything will go awry if you concurrently operate on
the handle. In Rust, however, the stdio handles are always locked, and there's
no way to not use them unlocked in libstd. Due to that change we've always had
synchronized access to these handles, which means that Rust programs typically
"just work".
Conversely, though, this commit fixes the test case included, which exhibits
behavior that other programs Rust spawns may attempt to execute. Namely, the
stdio handles may be concurrently used and having them in overlapped mode wreaks
havoc.
[link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343Closes#38811
fix promotion of MIR terminators
promotion of MIR terminators used to try to promote the destination it
is trying to promote, leading to stack overflow.
Also clean up the code in `promote_temp` a bit to make it more understandable.
Fixes#37991.
cc @nikomatsakis
r? @eddyb
Dont check stability for items that are not pub to universe.
Dont check stability for items that are not pub to universe.
In other words, skip it for private and even `pub(restricted)` items, because stability checks are only relevant to things visible in other crates.
Fix#38412.
resolve: don't `unused_qualifications`-check global paths
We started `unused_qualifications`-checking global paths in #38014, causing #38682.
Fixes#38682.
r? @nrc
Properly ban the negation of unsigned integers in type-checking.
Lint-time banning of unsigned negation appears to be vestigial from a time it was feature-gated.
But now it always errors and we do have the ability to deref the checking of e.g. `-0`, through the trait obligation fulfillment context, which will only succeed/error when the `0` gets inferred to a specific type.
The two removed tests are the main reason for finally cleaning this up, they need changing all the time when refactoring the HIR-based `rustc_const_eval` and/or `rustc_passes::consts`, as warnings pile up.
Some i128 tests
* Add some FFI tests for i128 on architectures where we have sort of working "C" FFI support. On all other architectures we ignore the test.
* enhance the u128 overflow tests
Additional cleanup to rustc_trans
Removes `BlockAndBuilder`, `FunctionContext`, and `MaybeSizedValue`.
`LvalueRef` is used instead of `MaybeSizedValue`, which has the added benefit of making functions operating on `Lvalue`s be able to take just that (since it encodes the type with an `LvalueTy`, which can carry discriminant information) instead of a `MaybeSizedValue` and a discriminant.
r? @eddyb
This commit fixes a mistake introduced in #31618 where overlapped handles were
leaked to child processes on Windows. On Windows once a handle is in overlapped
mode it should always have I/O executed with an instance of `OVERLAPPED`. Most
child processes, however, are not prepared to have their stdio handles in
overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle.
Now we haven't had any odd behavior in Rust up to this point, and the original
bug was introduced almost a year ago. I believe this is because it turns out
that if you *don't* pass an `OVERLAPPED` then the system will [supply one for
you][link]. In this case everything will go awry if you concurrently operate on
the handle. In Rust, however, the stdio handles are always locked, and there's
no way to not use them unlocked in libstd. Due to that change we've always had
synchronized access to these handles, which means that Rust programs typically
"just work".
Conversely, though, this commit fixes the test case included, which exhibits
behavior that other programs Rust spawns may attempt to execute. Namely, the
stdio handles may be concurrently used and having them in overlapped mode wreaks
havoc.
[link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343Closes#38811
rustc: Stabilize the `proc_macro` feature
This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the
compiler to stabilize the "Macros 1.1" feature of the language. Many more
details can be found on the tracking issue, #35900.
Closes#35900
Fix transmute::<T, U> where T requires a bigger alignment than U
For transmute::<T, U> we simply pointercast the destination from a U
pointer to a T pointer, without providing any alignment information,
thus LLVM assumes that the destination is aligned to hold a value of
type T, which is not necessarily true. This can lead to LLVM emitting
machine instructions that assume said alignment, and thus cause aborts.
To fix this, we need to provide the actual alignment to store_operand()
and in turn to store() so they can set the proper alignment information
on the stores and LLVM can emit the proper machine instructions.
Fixes#32947
prefer hyphens in test files named after issue numbers
We have a lot of tests with filenames honoring particular issues by
number. Typically, these are called issue-${issue_no}.rs (note the
hyphen):
```
$ find . -regextype posix-egrep -regex '.*/issue-[0-9]*.rs' | wc
1289 1289 35935
```
We also had a much smaller number of files that are like this, but don't
have a hyphen in between the substring `issue` and the number:
```
$ find . -regextype posix-egrep -regex '.*/issue[0-9]*.rs'
./debuginfo/issue14411.rs
./debuginfo/issue12886.rs
./debuginfo/issue13213.rs
./debuginfo/issue22656.rs
./debuginfo/issue7712.rs
./compile-fail/issue32829.rs
./run-pass/issue24353.rs
./run-pass/issue34796.rs
./run-pass/issue18173.rs
./run-pass/issue22346.rs
./run-pass/auxiliary/issue13507.rs
./run-pass/issue26127.rs
./run-pass/issue22008.rs
./run-pass/issue34569.rs
./run-pass/issue29927.rs
./run-pass/issue36260.rs
```
Some would argue that the inconsistency is æsthetically displeasing,
hence this trivial patch. (Note that run-pass/auxiliary/issue13507.rs
has an excuse; it's `use`d in run-pass/issue-13507-2.rs; the matter of
there being two different compile-fail tests with different name
conventions for issue no. 32829 is also neglected here for the sake of
keeping this trivial cleanup patch as trivial as possible for ease of
review.)
Fix is_uninhabited for enum types. It used to assume that an enums variant's
fields were all private.
Fix MIR generation for irrefutable Variant pattern matches. This allows code
like this to work:
let x: Result<32, !> = Ok(123);
let Ok(y) = x;
Carry type information on dummy wildcard patterns. Sometimes we need to expand
these patterns into their constructors and we don't want to be expanding a
TyError into a Constructor::Single.
Fix debuginfo for unsized struct members
The member was given the size of a fat pointer, which caused
llvm to emit DWARF attributes for a 128-bit bitfield.
This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the
compiler to stabilize the "Macros 1.1" feature of the language. Many more
details can be found on the tracking issue, #35900.
Closes#35900
