| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
By using 'impl trait', it's possible to create a self-referential
type as follows:
fn foo() -> impl Copy { foo }
This is a function which returns itself.
Normally, the signature of this function would be impossible
to write - it would look like 'fn foo() -> fn() -> fn() ...'
e.g. a function which returns a function, which returns a function...
Using 'impl trait' allows us to avoid writing this infinitely long
type. While it's useless for practical purposes, it does compile and run
However, issues arise when we try to generate llvm debuginfo for such a
type. All 'impl trait' types (e.g. ty::Opaque) are resolved when we
generate debuginfo, which can lead to us recursing back to the original
'fn' type when we try to process its return type.
To resolve this, I've modified debuginfo generation to account for these
kinds of weird types. Unfortunately, there's no 'correct' debuginfo that
we can generate - 'impl trait' does not exist in debuginfo, and this
kind of recursive type is impossible to directly represent.
To ensure that we emit *something*, this commit emits dummy
debuginfo/type names whenever it encounters a self-reference. In
practice, this should never happen - it's just to ensure that we can
emit some kind of debuginfo, even if it's not particularly meaningful
Fixes #58463
|
|
|
|
Fix generic argument lookup for Self
Rewrite the SelfCtor early and use the replacement Def when
calculating the path_segs.
Note that this also changes which def is seen by the code that
computes user_self_ty and is_alias_variant_ctor; I don't see a
immediate issue with that, but I'm not 100% clear on the
implications.
Fixes #57924
r? @eddyb
|
|
|
|
Rewrite the SelfCtor early and use the replacement Def when
calculating the path_segs.
Note that this also changes which def is seen by the code that
computes user_self_ty and is_alias_variant_ctor; I don't see a
immediate issue with that, but I'm not 100% clear on the
implications.
Fixes #57924
|
|
|
|
This is required at the very least in order to evaluate associated
constants for arrays (see #58212).
|
|
|
|
|
|
|
|
|
|
|
|
address some FIXME whose associated issues were marked as closed
part of #44366
|
|
|
|
r=nikomatsakis
Less conservative uninhabitedness check
Extends the uninhabitedness check to structs, non-empty enums, tuples and arrays.
Pulled out of #47291 and #50262.
Fixes https://github.com/rust-lang/rust/issues/54586.
r? @nikomatsakis
|
|
pnkfelix:issue-54153-linkage-sometimes-requires-optimizations, r=nikic
fix issue 54153 by not testing issue-18804 on Windows nor OS X.
Fix #54153
|
|
hr_lifetime_in_assoc_type warning
|
|
|
|
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
It should be possible to revert this commit when we're done with the
warnings.
|
|
As a drive-by, add `-C no-prepopulate-passes` as suggested by nikic.
|
|
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
|
|
|
|
|
Stabilize macro_literal_matcher
This followed FCP in #35625.
Closes #35625
|
|
|
|
|
|
Since lexical MIR borrow check is gone, and validation no longer uses
these, they can be removed.
|
|
Take supertraits into account when calculating associated types
Fixes #24010 and #23856. Applies to trait aliases too.
As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See #50589 for more info.
I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+.
N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this.
CC @carllerche @theemathas @durka @mbrubeck
|
|
|
|
|
|
I removed the original file that more completely captured the original
crate's tests, as its source crate
(https://crates.io/crates/collection) is licensed under GPL3, and I
suspect that license is not loose enough for me to put into our repo
under our MIT/Apache licensing.
(Would it be an option to attach the GPL3 licesne to just the one
test? Probably. But do I want to bother with it that that point?
Nope!)
|
|
|
|
under #54986.
|
|
Fix dead code lint for functions using impl Trait
Fixes https://github.com/rust-lang/rust/issues/54754
This is a minimal fix that doesn't add any new queries or touches unnecessary code. Please nominate for beta backport if wanted.
|
|
oli-obk:mögen_konstante_funktionen_doch_bitte_endlich_stabil_sein, r=Centril
Stabilize `min_const_fn`
tracking issue: #53555
r? @Centril
|
|
rustc: Allow `#[no_mangle]` anywhere in a crate
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
|
|
|
|
|
|
|
|
do not promote comparing function pointers
This *could* break existing code that relied on fn ptr comparison getting promoted to `'static` lifetime.
Fixes https://github.com/rust-lang/rust/issues/54696
|
|
make run-pass tests with empty main just compile-pass tests
Many run-pass tests have an empty main, so there is not actually any point in running them. This makes them `compile-pass` tests instead, saving some time (generating the binary and then running it).
For now I did this only for `run-pass/issues`; if there is interest I can also do it for the other directories. I used `^\s*fn\s+main\(\s*\)\s*\{\s*\}` as regexp to identify these files.
|
|
|
|
|
