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 f189d7a6937 and 9d11b089ad1. 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).
Emphasise that these functions look at the disk, not just the path
I thought that `PathBuf::new("foo/bar/").is_dir()` is always true, because the path ends in `/`. However, this is not what `is_dir()` function does. So I've updated the docs to make it clear.
