Also, update the affected tests. This seems strictly better but it is
actually more permissive than I initially intended. In particular it
accepts this
```
forall<'a, 'b> {
exists<'intersection> {
'a: 'intersection,
'b: 'intersection,
}
}
```
and I'm not sure I want to accept that. It implies that we have a
`'empty` in the new universe intoduced by the `forall`.
Prefer accessible paths in 'use' suggestions
This PR addresses issue https://github.com/rust-lang/rust/issues/26454, where `use` suggestions are made for paths that don't work. For example:
```rust
mod foo {
mod bar {
struct X;
}
}
fn main() { X; } // suggests `use foo::bar::X;`
```
This commit fixes a regression introduced in #73317 where an oversight
meant that `config.toml` was assumed to exist.
Signed-off-by: David Wood <david@davidtw.co>
Fixes#46099
Previously, we would check the 'move' and 'use' spans to see if we
should emit this message. However, this can give false positives when
macros are involved, since two distinct expressions may end up with the
same span.
Instead, we check the actual MIR `Location`, which eliminates false
positives.
Cache flags and escaping vars for predicates
With predicates becoming interned (rust-lang/compiler-team#285) this is now possible and could be a perf win. It would become an even larger win once we have recursive predicates.
cc @lcnr @nikomatsakis
r? @ghost
Upgrade Chalk
Things done in this PR:
- Upgrade Chalk to `0.11.0`
- Added compare-mode=chalk
- Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk
- Removed `RustDefId` since the builtin type support is there
- Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk
- Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`)
- Lower `RegionOutlives` and `ObjectSafe` predicates
- Lower `Dyn` without the region
- Handle `Int`/`Float` `CanonicalVarKind`s
- Uncomment some Chalk tests that actually work now
- Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different
r? @nikomatsakis
This fixes an issue with the following sample:
mod foo {
mod inaccessible {
pub struct X;
}
pub mod avail {
pub struct X;
}
}
fn main() { X; }
Instead of suggesting both `use crate::foo::inaccessible::X;` and `use
crate::foo::avail::X;`, it should only suggest the latter.
It is done by trimming the list of suggestions from inaccessible paths
if accessible paths are present.
Visibility is checked with `is_accessible_from` now instead of being
hard-coded.
-
Some tests fixes are trivial, and others require a bit more explaining,
here are my comments:
src/test/ui/issues/issue-35675.stderr: Only needs to make the enum
public to have the suggestion make sense.
src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't
help because its constructor is not visible, so the attempted
constructor does not work. In that case, it's better not to suggest it.
The case where the constructor is public is covered in `issue-26545.rs`.
Enable LLVM zlib
Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error:
`rust-lld: error: ...: contains a compressed section, but zlib is not available`
This enables zlib when building LLVM.
