Unskip some tests on AArch64
I've been running the test suite remotely on an Acer Chromebook R13 and natively on an ARM Juno developer board, both AArch64 devices. Most of the tests that are skipped on AArch64 are due to testing stdcall/fastcall/x86-specific code or the debugger, but I've found a few tests that could be enabled there.
These have been skipped previously due to failing on the `aarch64-linux-android` and `mac-android` buildbots, more than 2 years ago (#23471, #23695). It seems we don't test those platforms any more, but as they do work on AArch64 Linux, I'd like to propose re-enabling them. All of them pass on my devices.
Add L4Re Support in librustc_back
Add experimental support for x86_64-unknown-l4re-uclibc target, which covers the L4 Runtime Environment.
This pull request contains the changes that have to be made to librustc_back. It follows the changes humenda made in pull request https://github.com/rust-lang/libc/pull/591 to libc.
Next steps will be the modifications to the needed libraries. (libstd, liballoc_system, libpanic_abort, libunwind)
Thanks to humenda for reviewing.
incr.comp.: Assert that no DepNode is re-opened (see issue #42298).
This PR removes the last occurrence of DepNode re-opening and adds an assertion that prevents our doing so in the future too. The DepGraph should no be guaranteed to be cycle free.
r? @nikomatsakis
EDIT: Closes https://github.com/rust-lang/rust/issues/42298
Link LLVM tools dynamically
Set `LLVM_LINK_LLVM_DYLIB=ON` -- "If enabled, tools will be linked with
the libLLVM shared library." Rust doesn't ship any of the LLVM tools,
and only needs a few at all for some test cases, so statically linking
the tools is just a waste of space. I've also had memory issues on
slower machines with LLVM debuginfo enabled, when several tools start
linking in parallel consuming several GBs each.
With the default configuration, `build/x86_64-unknown-linux-gnu/llvm`
was 1.5GB before, now down to 731MB. The difference is more drastic
with `--enable-llvm-release-debuginfo`, from 28GB to "only" 13GB.
This does not change the linking behavior of `rustc_llvm`.
Add a more precise error message for issue #35976
When trying to perform static dispatch on something which derefs to a trait object, and the target trait is not in scope, we had confusing error messages if the target method had a `Self: Sized` bound. We add a more precise error message in this case: "consider using trait ...".
Fixes#35976.
r? @nikomatsakis
field does not exist error: note fields if Levenshtein suggestion fails
When trying to access or initialize a nonexistent field, if we can't infer what
field was meant (by virtue of the purported field in the source being a small
Levenshtein distance away from an actual field, suggestive of a typo), issue a
note listing all the available fields. To reduce terminal clutter, we don't
issue the note when we have a `find_best_match_for_name` Levenshtein
suggestion: the suggestion is probably right.
The third argument of the call to `find_best_match_for_name` is changed to
`None`, accepting the default maximum Levenshtein distance of one-third of the
identifier supplied for correction. The previous value of `Some(name.len())`
was overzealous, inappropriately very Levenshtein-distant suggestions when the
attempted field access could not plausibly be a mere typo. For example, if a
struct has fields `mule` and `phone`, but I type `.donkey`, I'd rather the
error have a note listing that the available fields are, in fact, `mule` and
`phone` (which is the behavior induced by this patch) rather than the error
asking "did you mean `phone`?" (which is the behavior on master). The "only
find fits with at least one matching letter" comment was accurate when it was
first introduced in 09d992471 (January 2015), but is a vicious lie in its
present context before a call to `find_best_match_for_name` and must be
destroyed (replacing every letter is within a Levenshtein distance of name.len()).
The present author claims that this suffices to resolve#42599.
Add MIR Validate statement
This adds statements to MIR that express when types are to be validated (following [Types as Contracts](https://internals.rust-lang.org/t/types-as-contracts/5562)). Obviously nothing is stabilized, and in fact a `-Z` flag has to be passed for behavior to even change at all.
This is meant to make experimentation with Types as Contracts in miri possible. The design is definitely not final.
Cc @nikomatsakis @aturon
This is a follow-up to f189d7a693 and 9d11b089ad. While `-z ignore`
is what needs to be passed to the Solaris linker, because gcc is used as
the default linker, both that form and `-Wl,-z -Wl,ignore` (including
extra double quotes) need to be taken into account, which explains the
more complex regular expression.
When trying to perform static dispatch on something which derefs
to a trait object, and the target trait is not in scope, we had
confusing error messages if the target method had a
`Self: Sized` bound. We add a more precise error message in this
case: "consider using trait ...".
Fixes#35976.
extend config.toml doc for debug-assertions
Even after I knew that I had to change config.toml to get any printing from debug! and trace!, going over the entire fail did not make it clear to me that `debug-assertions` is the option controlling that.
Update RLS and deps
This PR further moves towards configuring save-analysis using the rls-data Config struct. We remove completely the concept of api_crate. Updates the RLS so the client is expecting these changes and which pulls in a commit re-enabling all RLS tests (been disabled due to a span error for a while).
