Previously if --extern was specified it would not override crates in the
standard distribution, leading to issues like #21771. This commit alters the
behavior such that if --extern is passed then it will always override any other
choice of crates and no previous match will be used (unless it is the same path
as --extern).
Closes#21771
Hi.
Here a commit in order to add OpenBSD support to rust.
- tests status:
run-pass: test result: ok. 1879 passed; 0 failed; 24 ignored; 0 measured
run-fail: test result: ok. 81 passed; 0 failed; 5 ignored; 0 measured
compile-fail: test result: ok. 1634 passed; 0 failed; 22 ignored; 0 measured
run-pass-fulldeps: test result: ok. 22 passed; 0 failed; 1 ignored; 0 measured
compile-fail-fulldeps: test result: ok. 13 passed; 0 failed; 0 ignored; 0 measured
- The current implementation of load_self function (src/libstd/sys/unix/os.rs) isn't optimal as under OpenBSD I haven't found a reliable method to get the filename of a running process. The current implementation is enought for bootstrapping purpose.
- I have disable `run-pass/tcp-stress.rs` test under openbsd. When run manually, the test pass, but when run under `compiletest`, it timeout and echo continuoulsy `Too many open files`.
- For building with jemalloc, a more recent version of jemalloc would be mandatory. See https://github.com/jemalloc/jemalloc/pull/188 for more details.
Previously if --extern was specified it would not override crates in the
standard distribution, leading to issues like #21771. This commit alters the
behavior such that if --extern is passed then it will always override any other
choice of crates and no previous match will be used (unless it is the same path
as --extern).
Closes#21771
This is a bit of cleanup work to clean out some old deprecated flags and deprecated lint names from the compiler (they've been deprecated for quite awhile now).
This also notably puts `--pretty` behind the `-Z unstable-options` flag (where it was supposed to be previously).
This commit removes a number of deprecated flags from the compiler:
* opt-level => -C opt-level
* debuginfo => -C debuginfo
* print-crate-name => --print crate-name
* print-file-name => --print file-names
* no-trans => -Z no-trans
* no-analysis => -Z no-analysis
* parse-only => -Z parse-only
* dep-info => --emit dep-info
This commit also moves the --pretty flag behind `-Z unstable-options` as the
pretty printer will likely not be stable for 1.0
cc #19051
The script is intended as a tool for doing every sort of verifications amenable to Rustdoc's HTML output. For example, link checkers would go to this script. It already parses HTML into a document tree form (with a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated to use `htmldocck.py` and got their `verify.sh` removed. In the future they may go to a dedicated directory with htmldocck running by default. The detailed explanation of test scripts is provided as a docstring of htmldocck.
cc #19723
The script is intended as a tool for doing every sort of verifications
amenable to Rustdoc's HTML output. For example, link checkers would go
to this script. It already parses HTML into a document tree form (with
a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated
to use `htmldocck.py` and got their `verify.sh` removed. In the future
they may go to a dedicated directory with htmldocck running by default.
The detailed explanation of test scripts is provided as a docstring of
htmldocck.
cc #19723
This stops the compiler ICEing on the use of SIMD types in FFI signatures. It emits correct code for LLVM intrinsics, but I am quite unsure about the ABI handling in general so I've added a new feature gate `simd_ffi` to try to ensure people don't use it without realising there's a non-trivial risk of codegen brokenness.
Closes#20043.
I don't know if this handling of SIMD types is correct for the C ABI on
all platforms, so lets add an even finer feature gate than just the
`simd` one.
The `simd` one can be used with (relatively) little risk of complete
nonsense, the reason for it is that it is likely that things will
change. Using the types in FFI with an incorrect ABI will at best give
absolute nonsense results, but possibly cause serious breakage too, so
this is a step up in badness, hence a new feature gate.
This just compiles a test using SIMD in FFI (mostly importing LLVM
intrinsics) for almost all rustc's supported platforms, but not linking
it or running it, so there's absolutely no guarantee that this is correct.
With the addition of separate search paths to the compiler, it was intended that
applications such as Cargo could require a `--extern` flag per `extern crate`
directive in the source. The system can currently be subverted, however, due to
the `existing_match()` logic in the crate loader.
When loading crates we first attempt to match an `extern crate` directive
against all previously loaded crates to avoid reading metadata twice. This "hit
the cache if possible" step was erroneously leaking crates across the search
path boundaries, however. For example:
extern crate b;
extern crate a;
If `b` depends on `a`, then it will load crate `a` when the `extern crate b`
directive is being processed. When the compiler reaches `extern crate a` it will
use the previously loaded version no matter what. If the compiler was not
invoked with `-L crate=path/to/a`, it will still succeed.
This behavior is allowing `extern crate` declarations in Cargo without a
corresponding declaration in the manifest of a dependency, which is considered
a bug.
This commit fixes this problem by keeping track of the origin search path for a
crate. Crates loaded from the dependency search path are not candidates for
crates which are loaded from the crate search path.
With the addition of separate search paths to the compiler, it was intended that
applications such as Cargo could require a `--extern` flag per `extern crate`
directive in the source. The system can currently be subverted, however, due to
the `existing_match()` logic in the crate loader.
When loading crates we first attempt to match an `extern crate` directive
against all previously loaded crates to avoid reading metadata twice. This "hit
the cache if possible" step was erroneously leaking crates across the search
path boundaries, however. For example:
extern crate b;
extern crate a;
If `b` depends on `a`, then it will load crate `a` when the `extern crate b`
directive is being processed. When the compiler reaches `extern crate a` it will
use the previously loaded version no matter what. If the compiler was not
invoked with `-L crate=path/to/a`, it will still succeed.
This behavior is allowing `extern crate` declarations in Cargo without a
corresponding declaration in the manifest of a dependency, which is considered
a bug.
This commit fixes this problem by keeping track of the origin search path for a
crate. Crates loaded from the dependency search path are not candidates for
crates which are loaded from the crate search path.
As a result of this fix, this is a likely a breaking change for a number of
Cargo packages. If the compiler starts informing that a crate can no longer be
found, it likely means that the dependency was forgotten in your Cargo.toml.
[breaking-change]
This makes the tests much easier to maintain; the particular details
of the labels attached to exiting scopes is not worth the effort
required to keep it up to date as things change in the compiler
internals.
This commit takes a first pass at stabilizing `std::thread`:
* It removes the `detach` method in favor of two constructors -- `spawn`
for detached threads, `scoped` for "scoped" (i.e., must-join)
threads. This addresses some of the surprise/frustrating debug
sessions with the previous API, in which `spawn` produced a guard that
on destruction joined the thread (unless `detach` was called).
The reason to have the division in part is that `Send` will soon not
imply `'static`, which means that `scoped` thread creation can take a
closure over *shared stack data* of the parent thread. On the other
hand, this means that the parent must not pop the relevant stack
frames while the child thread is running. The `JoinGuard` is used to
prevent this from happening by joining on drop (if you have not
already explicitly `join`ed.) The APIs around `scoped` are
future-proofed for the `Send` changes by taking an additional lifetime
parameter. With the current definition of `Send`, this is forced to be
`'static`, but when `Send` changes these APIs will gain their full
flexibility immediately.
Threads that are `spawn`ed, on the other hand, are detached from the
start and do not yield an RAII guard.
The hope is that, by making `scoped` an explicit opt-in with a very
suggestive name, it will be drastically less likely to be caught by a
surprising deadlock due to an implicit join at the end of a scope.
* The module itself is marked stable.
* Existing methods other than `spawn` and `scoped` are marked stable.
The migration path is:
```rust
Thread::spawn(f).detached()
```
becomes
```rust
Thread::spawn(f)
```
while
```rust
let res = Thread::spawn(f);
res.join()
```
becomes
```rust
let res = Thread::scoped(f);
res.join()
```
[breaking-change]
This warning has been around in the compiler for quite some time now, but the
real place for a warning like this, if it should exist, is in Cargo, not in the
compiler itself. It's a first-class feature of Cargo that multiple versions of a
crate can be compiled into the same executable, and we shouldn't be warning
about our first-class features.
