Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest
version of the UEFI specification at the time of commit (UEFI spec 2.8,
URL below). The specification says that for x86_64, we should follow the
win64 ABI, while on all other supported platforms (ia32, itanium, arm,
arm64 and risc-v), we should follow the C ABI.
To simplify the implementation, we will simply follow the C ABI on all
platforms except x86_64, even those technically unsupported by the UEFI
specification.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
(Or more precisely, a pair of such traits: one for `derive(PartialEq)` and one
for `derive(Eq)`.)
((The addition of the second marker trait, `StructuralEq`, is largely a hack to
work-around `fn (&T)` not implementing `PartialEq` and `Eq`; see also issue
rust-lang/rust#46989; otherwise I would just check if `Eq` is implemented.))
Note: this does not use trait fulfillment error-reporting machinery; it just
uses the trait system to determine if the ADT was tagged or not. (Nonetheless, I
have kept an `on_unimplemented` message on the new trait for structural_match
check, even though it is currently not used.)
Note also: this does *not* resolve the ICE from rust-lang/rust#65466, as noted
in a comment added in this commit. Further work is necessary to resolve that and
other problems with the structural match checking, especially to do so without
breaking stable code (adapted from test fn-ptr-is-structurally-matchable.rs):
```rust
fn r_sm_to(_: &SM) {}
fn main() {
const CFN6: Wrap<fn(&SM)> = Wrap(r_sm_to);
let input: Wrap<fn(&SM)> = Wrap(r_sm_to);
match Wrap(input) {
Wrap(CFN6) => {}
Wrap(_) => {}
};
}
```
where we would hit a problem with the strategy of unconditionally checking for
`PartialEq` because the type `for <'a> fn(&'a SM)` does not currently even
*implement* `PartialEq`.
----
added review feedback:
* use an or-pattern
* eschew `return` when tail position will do.
* don't need fresh_expansion; just add `structural_match` to appropriate `allow_internal_unstable` attributes.
also fixed example in doc comment so that it actually compiles.
Fix default "disable-shortcuts" feature value
Follow-up of https://github.com/rust-lang/rust/pull/65656
It fixes the bad handling of the default value of the feature (which would disable shortcut by default, which is bad!).
r? @Dylan-DPC
cc @kinnison
Prevent unnecessary allocation in PathBuf::set_extension.
It was allocating a new `OsString` that was immediately dropped after using it with `set_file_name`. Now it directly changes the extension in the original buffer, without touching the rest of the file name or allocating a temporary string.
Fix check of `statx` and handle EPERM
Should fix#65662https://github.com/rust-lang/rust/issues/65662#issuecomment-544593939
> I think a reasonable solution might be to do something like try to stat AT_CWD initially and if that fails with EPERM or ENOSYS we disable the syscall entirely, otherwise it's cached as always good to use.
r? @alexcrichton
Intern place projection
This should sit on top of https://github.com/rust-lang/rust/pull/65197. After that one merged, I'm gonna rebase on top of it.
The important commits are the last three and there's a bunch of code repetition that I'm going to remove but for that I need to refactor some things that probably need to be added before this PR.
Anyway this work helps as is because we can run perf tests :).
r? @oli-obk /cc @nikomatsakis
Fix the start/end byte positions in the compiler JSON output
Track the changes made during normalization in the `SourceFile` and use this information to correct the `start_byte` and `end_byte` fields in the JSON output.
This should ensure the start/end byte fields can be used to index the original file, even if Rust normalized the source code for parsing purposes. Both CRLF to LF and BOM removal are handled with this one.
The rough plan was discussed with @matklad in rust-lang-nursery/rustfix#176 - although I ended up going with `u32` offset tracking so I wouldn't need to deal with `u32 + i32` arithmetics when applying the offset to the span byte positions.
Fixes#65029
Stabilize `#[non_exhaustive]` (RFC 2008)
Fixes#44109.
This pull request stabilizes the `#[non_exhaustive]` attribute, which is used to indicate that a type will have more fields / variants added in the future. It can be applied to `struct`s, `enum`s and `enum` variants. See https://github.com/rust-lang/rust/issues/44109#issuecomment-533356866 for the stabilization report.
r? @Centril
ignore uninhabited non-exhaustive variant fields
Fixes#65157.
This PR modifies the uninhabitedness checking so that the fields of
a non-exhaustive variant (which is not local) are ignored if they are
uninhabited. This is an improvement over the previous behaviour which
considered all non-local non-exhaustive variants useful because
unreachable patterns are now detected.
r? @arielb1
cc @varkor
Add by-value iterator for arrays
This adds an iterator that can iterate over arrays by value, yielding all elements by value. However, **this PR does _not_ add a corresponding `IntoIterator` impl for arrays**. The `IntoIterator` impl needs some discussion about backwards-compatibility that should take place in a separate PR. With this patch, this code should work (but there is currently still a bug):
```rust
#![feature(array_value_iter)]
use std::array::IntoIter;
let arr = [1, 2, 3];
for x in IntoIter::new(arr) {
println!("{}", x);
}
```
**TODO**:
- [x] Get initial feedback
- [x] Add tests
- [x] Figure out why stage1 produces weird bugs ([comment](https://github.com/rust-lang/rust/pull/62959#issuecomment-516016524))
- [x] Add UI tests as mentioned [here](https://github.com/rust-lang/rust/pull/62959#discussion_r307061894) (will do that soon-ish)
- [x] Fix [this new bug](https://github.com/rust-lang/rust/pull/62959#issuecomment-544732159)
**Notes for reviewers**
- Is the use of `MaybeUninit` correct here? I think it has to be used due to the `Clone` impl which has to fill the dead array elements with something, but cannot fill it with a correct instance.
- Are the unit tests sufficient?
CC #25725
