Avoid repetition on “use of unstable library feature 'rustc_private'”
This PR fixes the error by only emitting it when the span contains a real file (is not inside a macro) - and making sure it's emitted only once per span.
The first check was needed because spans-within-macros seem to differ a lot and "fixing" them to the real location is not trivial (and the method that does this is private to another module). It also feels like there always will be an error on import, with the real file name, so not sure there's a point to re-emit the same error at macro use.
Fix#44953.
Implement RFC 1861: Extern types
A few notes :
- Type parameters are not supported. This was an unresolved question from the RFC. It is not clear how useful this feature is, and how variance should be treated. This can be added in a future PR.
- `size_of_val` / `align_of_val` can be called with extern types, and respectively return 0 and 1. This differs from the RFC, which specified that they should panic, but after discussion with @eddyb on IRC this seems like a better solution.
If/when a `DynSized` trait is added, this will be disallowed statically.
- Auto traits are not implemented by default, since the contents of extern types is unknown. This means extern types are `!Sync`, `!Send` and `!Freeze`. This seems like the correct behaviour to me.
Manual `unsafe impl Sync for Foo` is still possible.
- This PR allows extern type to be used as the tail of a struct, as described by the RFC :
```rust
extern {
type OpaqueTail;
}
#[repr(C)]
struct FfiStruct {
data: u8,
more_data: u32,
tail: OpaqueTail,
}
```
However this is undesirable, as the alignment of `tail` is unknown (the current PR assumes an alignment of 1). Unfortunately we can't prevent it in the general case as the tail could be a type parameter :
```rust
#[repr(C)]
struct FfiStruct<T: ?Sized> {
data: u8,
more_data: u32,
tail: T,
}
```
Adding a `DynSized` trait would solve this as well, by requiring tail fields to be bound by it.
- Despite being unsized, pointers to extern types are thin and can be casted from/to integers. However it is not possible to write a `null<T>() -> *const T` function which works with extern types, as I've explained here : https://github.com/rust-lang/rust/issues/43467#issuecomment-321678621
- Trait objects cannot be built from extern types. I intend to support it eventually, although how this interacts with `DynSized`/`size_of_val` is still unclear.
- The definition of `c_void` is unmodified
Return 0 as an exit status when no subcommand is given to bootstrap
Running `./x.py` emits usage and error messages when no subcommand is given:
```
Usage: x.py <subcommand> [options] [<paths>...]
Subcommands:
build Compile either the compiler or libraries
test Build and run some test suites
bench Build and run some benchmarks
doc Build documentation
clean Clean out build directories
dist Build distribution artifacts
install Install distribution artifacts
To learn more about a subcommand, run `./x.py <subcommand> -h`
failed to run: /home/topecongiro/rust/build/bootstrap/debug/bootstrap
```
IMHO the last line is unnecessary. This PR removes it by changing the return code of `bootstrap` to 0 when no sub command is given.
Use expect for current_dir on librustc/session mod
Reference bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871638
Like described on the reference bug report:
~~~
$ mkdir dir
$ cd dir
$ rm -rf ../dir
$ RUST_BACKTRACE=1 rustc -C target-cpu=help
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', src/libcore/result.rs:837
stack backtrace:
1: 0x7f7d23970dda - <unknown>
2: 0x7f7d2398305f - <unknown>
3: 0x7f7d2397f8a5 - <unknown>
4: 0x7f7d2397ffc7 - std::panicking::rust_panic_with_hook::h109e116a3a861224
5: 0x7f7d2397fe54 - <unknown>
6: 0x7f7d2397fd79 - std::panicking::begin_panic_fmt::h26713cea9bce3ab0
7: 0x7f7d2397fd07 - rust_begin_unwind
8: 0x7f7d239cb41d - core::panicking::panic_fmt::hcfbb59eeb7f27f75
9: 0x7f7d20be63d3 - <unknown>
10: 0x7f7d20d6ebcc - rustc::session::build_session_::h7a3559f2373a5d05
11: 0x7f7d20d6dd7e - rustc::session::build_session_with_codemap::h68bc7bcd2f34eee4
12: 0x7f7d20d6d72c - rustc::session::build_session::h437fda3c327a8bde
13: 0x7f7d23d26030 - <rustc_driver::RustcDefaultCalls as rustc_driver::CompilerCalls<'a>>::no_input::h8047df7741757d1c
14: 0x7f7d23d21d27 - rustc_driver::run_compiler::hafe7bbfedf95a825
15: 0x7f7d23c57378 - <unknown>
16: 0x7f7d2398ae0a - __rust_maybe_catch_panic
17: 0x7f7d23c76fa8 - <unknown>
18: 0x7f7d2397eb74 - <unknown>
19: 0x7f7d1ed4f493 - start_thread
20: 0x7f7d23645afe - __clone
21: 0x0 - <unknown>
~~~
With this patch this will give instead:
~~~
error: Current directory is invalid: No such file or directory (os error 2)
~~~
configure.py: fix --disable-option-checking and extra config paths
- indexing 'option-checking' out of `known_args` had a type error
- when option checking is disabled, don't error on duplicate args, just take the last
- add config.toml stubs for datadir, infodir, and localstatedir (which were already accepted, but broken)
---
This fixes a regression from 1.21 to beta, when the configure script was rewritten in python.
Improve diagnostics when list of tokens has incorrect separators
Make `parse_seq_to_before_tokens` more resilient to error conditions. Where possible it is better if it can consume up to the final bracket before returning. This change improves the diagnostics in a couple of situations:
```
struct S(pub () ()); // omitted separator
use std::{foo. bar}; // used a similar but wrong separator
```
Fixes#44339
r? @petrochenkov
Bump to 1.23 and update bootstrap
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
Don't fail to build a manifest if a tarball is missing
This is guesswork because I can't test build_manifest nor do I know what is actually causing the error to begin with. My hypothesis is that when we try to find the version from the RLS tarball and the tarball is not there, then we panic. I attempt to fix this by making the version string optional, then not adding the RLS package, rename, and extension component if the version is missing.
In theory, this should fix the broken nightlies.
r? @alexcrichton
std: Optimize thread park/unpark implementation
This is an adaptation of alexcrichton/futures-rs#597 for the standard library.
The goal here is to avoid locking a mutex on the "fast path" for thread
park/unpark where you're waking up a thread that isn't sleeping or otherwise
trying to park a thread that's already been notified. Mutex performance varies
quite a bit across platforms so this should provide a nice consistent speed
boost for the fast path of these functions.
... specifically `datadir`, `infodir`, and `localstatedir`. These were
already accepted by `configure.py`, but it didn't have any place to put
the values.
Getting the value of this argument needs another level of indexing,
as `known_args` are stored in `{dict}[list](opt, value)` form.
Also, when option-checking is disabled, let this bypass the check that
options are only passed once, and just apply the last value.
std: Disable usage of mmap allocator in libbacktrace
This is sort of a long overdue change from the investigation in #29293
and #37477. The released binaries of rustc don't have debug information and so
don't actively suffer this problem but this can hit local development of rustc
and also larger programs compiled against libstd generating backtraces.
The main purpose of the mmap allocator in libacktrace is to be usable from a
signal handler, but we don't do that, so the normal allocator using malloc/free
should work well for us.
Don't emit the same compiler diagnostic twice.
This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.
Avoid unnecessary copies of arguments that are simple bindings
Initially MIR differentiated between arguments and locals, which
introduced a need to add extra copies assigning the argument to a
local, even for simple bindings. This differentiation no longer exists,
but we're still creating those copies, bloating the MIR and LLVM IR we
emit.
Additionally, the current approach means that we create debug info for
both the incoming argument (marking it as an argument), and then
immediately shadow it a local that goes by the same name. This can be
confusing when using e.g. "info args" in gdb, or when e.g. a debugger
with a GUI displays the function arguments separately from the local
variables, especially when the binding is mutable, because the argument
doesn't change, while the local variable does.
Initially MIR differentiated between arguments and locals, which
introduced a need to add extra copies assigning the argument to a
local, even for simple bindings. This differentiation no longer exists,
but we're still creating those copies, bloating the MIR and LLVM IR we
emit.
Additionally, the current approach means that we create debug info for
both the incoming argument (marking it as an argument), and then
immediately shadow it a local that goes by the same name. This can be
confusing when using e.g. "info args" in gdb, or when e.g. a debugger
with a GUI displays the function arguments separately from the local
variables, especially when the binding is mutable, because the argument
doesn't change, while the local variable does.
