| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update panic message to be clearer about env-vars
Esteban Kuber requested that the panic message make it clear
that `RUST_BACKTRACE=1` is an environment variable. This change
makes that clear.
I understand that this may simply be closed if the concept isn't accepted, and I'd be fine with that :-)
Fixes #56734
|
|
As a drive-by, add `-C no-prepopulate-passes` as suggested by nikic.
|
|
Esteban Kuber requested that the panic message make it clear
that `RUST_BACKTRACE=1` is an environment variable. This change
makes that clear. Wording provided in part by David Tolnay.
|
|
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
|
|
|
|
This was intended to land way back in 1.24, but it was backed out due to
breakage which has long since been fixed. An unstable `#[unwind]`
attribute can be used to tweak the behavior here, but this is currently
simply switching rustc's internal default to abort-by-default if an
`extern` function panics, making our codegen sound primarily (as
currently you can produce UB with safe code)
Closes #52652
|
|
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
|
|
|
|
|
|
|
|
|
|
Fix #56237: normalize type before deferred sizedness checking.
This seems to fix #56237, which was introduced by #56045. I don't thoroughly understand how this works, but the problem seemed to be a lack of normalization.
r? @cramertj
|
|
pass the parameter environment to `traits::find_associated_item`
dropping the param-env on the floor is obviously the wrong thing to do.
The ICE was probably exposed by #54490 adding the problem-exposing use of
`traits::find_associated_item`.
Fixes #55380.
r? @nikomatsakis
|
|
Utilize `?` instead of `return None`.
None
|
|
|
|
Stabilize self_in_typedefs feature
[**Tracking Issue**](https://github.com/rust-lang/rust/issues/49303)
r? @centril
|
|
dropping the param-env on the floor is obviously the wrong thing to do.
The ICE was probably exposed by #54490 adding the problem-exposing use of
`traits::find_associated_item`.
Fixes #55380.
|
|
Consider references and unions potentially inhabited during privacy-respecting inhabitedness checks
It isn't settled exactly how references to uninhabited types and unions of uninhabited types should act, but we should be more conservative here, as it's likely it will be permitted to soundly have values of such types.
This will also be more important in light of the changes at https://github.com/rust-lang/rust/pull/54125.
cc @RalfJung
|
|
|
|
|
|
Given the function
fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {}
Prior to 1.12 we dropped both `_x` and `_y` before the rest of their
respective parameters, since then we dropped `_x` and `_y` after. The
original order appears to be the correct order, as the value created
later is dropped first, so we revert to that order and add a test for
it.
|
|
Stabilize self_struct_ctor feature.
[**Tracking Issue**](https://github.com/rust-lang/rust/issues/51994)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize the int_to_from_bytes feature
Fixes #52963
FCP to merge completed: https://github.com/rust-lang/rust/issues/52963#issuecomment-416548327
|
|
Move a flaky process test out of libstd
This test ensures that everything in `env::vars()` is inherited but
that's not actually true because other tests may add env vars after we
spawn the process, causing the test to be flaky! This commit moves the
test to a run-pass test where it can execute in isolation.
Along the way this removes a lot of the platform specificity of the
test, using iteslf to print the environment instead of a foreign process.
|
|
Incorporate `dyn` into more comments and docs.
r? @rust-lang/docs
|
|
Stabilize macro_literal_matcher
This followed FCP in #35625.
Closes #35625
|
|
Check arg/ret sizedness at ExprKind::Path
This PR solves three problems:
- #50940: ICE on casting unsized tuple struct constructors
- Unsized tuple struct constructors were callable in presence of `unsized_locals`.
- https://github.com/rust-lang/rust/issues/48055#issuecomment-437178966: we cannot relax `Sized` bounds on stable functions because of fn ptr casting
These are caused by lack of `Sized`ness checks for arguments/retvals at **reference sites of `FnDef` items** (not call sites of the functions). Therefore we can basically add more `Sized` obligations on typeck. However, adding `Sized` obligations arbitrarily breaks type inference; to prevent that I added a new method `require_type_is_sized_deferred` which doesn't interfere usual type inference.
|
|
Fixes #52963
|
|
Add placeholder types
Fixes #48696 (handle universes in canonicalization of type inference vars), and fixes #55098.
|
|
Cleanup from lexical MIR borrowck removal
Lexical MIR borrowck was removed months ago now, and `EndRegion`s are no longer used for MIRI verification.
* Remove `rustc::mir::StatementKind::EndRegion` and the `-Zemit_end_regions` flag
* Use `RegionVid` instead of `Region` in BorrowSet
* Rewrite drop generation to create fewer goto terminators.
r? @nikomatsakis
|
|
|
|
This test ensures that everything in `env::vars()` is inherited but
that's not actually true because other tests may add env vars after we
spawn the process, causing the test to be flaky! This commit moves the
test to a run-pass test where it can execute in isolation.
Along the way this removes a lot of the platform specificity of the
test, using iteslf to print the environment instead of a foreign process.
|
|
|
|
|
|
|
|
|
|
Clean up some non-mod-rs stuff.
This includes the following:
- Remove unused `non_modrs_mods` from `ParseSess` which as only used for feature gate diagnostics.
- Remove the vestiges of the feature gate tests in `test/ui`, they were only partially removed during stabilization.
- Fix the run-pass test, it was accidentally removed during stabilization.
- Add a ui test to verify error behavior for missing inline-nested mods.
- Add some tests for `#[path]` for inline-nested mods (both mod and non-mod-rs).
- Enable the diagnostic tests on windows, they should be fixed by #49478.
cc @cramertj
|
|
Stress test for MPSC
`concurrent_recv_timeout_and_upgrade` reproduces a problem 100%
times on my MacBook with command:
```
./x.py test --stage 0 ./src/test/run-pass/mpsc_stress.rs
```
Thus it is commented out.
Other tests cases were useful for catching another test cases
which may arise during the fix.
This diff is a part of my previous rewrite attempt: #42883
CC #39364
|
|
Since lexical MIR borrow check is gone, and validation no longer uses
these, they can be removed.
|
