Fix cycle error with existential types
Fixes#61863
We now allow uses of `existential type`'s that aren't defining uses - that is, uses which don't constrain the underlying concrete type.
To make this work correctly, we also modify `eq_opaque_type_and_type` to not try to apply additional constraints to an opaque type. If we have code like this:
```rust
existential type Foo;
fn foo1() -> Foo { ... }
fn foo2() -> Foo { foo1() }
```
then `foo2` doesn't end up constraining `Foo`, which means that `foo2` will end up using the type `Foo` internally - that is, an actual `TyKind::Opaque`. We don't want to equate this to the underlying concrete type - we just need to enforce the basic equality constraint between the two types (here, the return type of `foo1` and the return type of `foo2`)
Optimize RefCell read borrowing
Instead of doing two comparisons we can do only one with a bit of cleverness.
LLVM currently can't do this optimization itself on x86-64.
Define built-in macros through libcore
This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.
The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.
Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).
Now when built-in macros have canonical definitions they can be imported or reexported without issues (https://github.com/rust-lang/rust/issues/61687).
Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (https://github.com/rust-lang/rust/issues/52269). This was an artificial restriction that could be worked around with import renaming anyway.
Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.
Fixes https://github.com/rust-lang/rust/issues/61687
Fixes https://github.com/rust-lang/rust/issues/61804
r? @eddyb
Rollup of 22 pull requests
Successful merges:
- #62084 (allow clippy::unreadable_literal in unicode tables)
- #62120 (Add missing type links in documentation)
- #62310 (Add missing doc links in boxed module)
- #62421 (Introduce `as_deref` to Option)
- #62583 (Implement Unpin for all raw pointers)
- #62692 (rustc: precompute the largest Niche and store it in LayoutDetails.)
- #62801 (Remove support for -Zlower-128bit-ops)
- #62828 (Remove vector fadd/fmul reduction workarounds)
- #62862 (code cleanup)
- #62904 (Disable d32 on armv6 hf targets)
- #62907 (Initialize the MSP430 AsmParser)
- #62956 (Implement slow-path for FirstSets::first)
- #62963 (Allow lexer to recover from some homoglyphs)
- #62964 (clarify and unify some type test names)
- #62970 (ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar)
- #62980 (std: Add more accessors for `Metadata` on Windows)
- #62983 (Remove needless indirection through Rc)
- #62985 (librustc_errors: Support ui-testing flag in annotate-snippet emitter)
- #63002 (error_index_generator should output stdout/stderr when it panics.)
- #63004 (Add test for issue-54062)
- #63007 (ci: debug network failures while downloading awscli from PyPI)
- #63009 (Remove redundant `mut` from variable declaration.)
Failed merges:
r? @ghost
ci: debug network failures while downloading awscli from PyPI
This adds some random debug code to our CI script while downloading awscli, to *hopefully* pinpoint what's causing the network failures.
r? @Mark-Simulacrum
cc #62967
error_index_generator should output stdout/stderr when it panics.
**bootstrap change**
Call error_index_generator tool using run_quiet which will additionally print std out and std err of the command when it returns an error.
(was `run` uses `run_silent` under the covers.)
Why: PR #62871 is hitting a build error but the panic isn't getting shown so its unclear what the problem is.
std: Add more accessors for `Metadata` on Windows
This commit adds accessors for more fields in `fs::Metadata` on Windows
which weren't previously exposed. There's two sources of `fs::Metadata`
on Windows currently, one from `DirEntry` and one from a file itself.
These two sources of information don't actually have the same set of
fields exposed in their stat information, however. To handle this the
platform-specific accessors of Windows-specific information all return
`Option` to return `None` in the case a metadata comes from a
`DirEntry`, but they're guaranteed to return `Some` if it comes from a
file itself.
This is motivated by some changes in CraneStation/wasi-common#42, and
I'm curious how others feel about this platform-specific functionality!
ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar
This PR fixes toolstate failing to push on the LinuxTools PR builder by gating the pushes on the new `TOOLSTATE_PUBLISH` environment variable, which is set on prod credentials but not on the PR ones. The old code checked whether the access token was set, but that doesn't work due to an Azure quirk.
For a bit of background, secret environment variables are not available by default, but each step needs to explicitly declare which secret vars to load:
```yaml
- bash: echo foo
env:
SECRET_VAR: $(SECRET_VAR)
```
This works fine when the variable is present but when it's missing, instead of setting `SECRET_VAR` to an empty string or just not setting it at all, Azure Pipelines puts the literal `$(SECRET_VAR)` as the content, which completly breaks the old check we had. I tried almost every thing to make this work in a sensible way, and the only conclusion I reached is to set the variable at the top level with the runtime expression evaluation syntax, which sets the variable to an empty string if missing:
```yaml
# At the top:
variables:
- name: MAYBE_SECRET_VAR
value: $[ variables.MAYBE_SECRET_VAR ]
# In the step:
- bash: echo foo
env:
SECRET_VAR: $(MAYBE_SECRET_VAR)
```
While that *could've worked* it was ugly and messy, so I just opted to add yet another non-secret variable.
r? @alexcrichton
fixes#62811
clarify and unify some type test names
* `is_mutable_pointer`: use `ptr` suffix for consistency with `is_region_ptr`, `is_fn_ptr`, `is_unsafe_ptr`.
* `is_pointer_sized`: the name is misleading as this only tests for pointer-sized *integers*, so rename to `is_ptr_sized_integral`.
Implement slow-path for FirstSets::first
When 2 or more sequences share the same span, we can't use the precomputed map
for their first set. So we compute it recursively.
Fixes#62831.
Disable d32 on armv6 hf targets
We already do this on armv7 targets. It seems that this now gets enabled by default if '+vfp2` is specified, so disable it explicitly.
Hopefully fixes#62841.
r? @alexcrichton
rustc: precompute the largest Niche and store it in LayoutDetails.
Since we only ever can use at most one niche, it makes sense to just store that in the layout, for the simplest caching (especially as it's almost trivial to compute).
There might be a speedup from this, but even if it's marginal now, the caching would be a more significant benefit for future optimization attempts.
