Fix#18604: next_power_of_two should panic on overflow
Fixes https://github.com/rust-lang/rust/issues/18604
Is it possible to write a test for this? My experiments showed `x.py test` running in release mode, so my attempt at a `#[should_panic]` didn't work.
Shorten paths to auxiliary files created by tests
I'm hitting issues with long file paths to object files created by the test suite, similar to https://github.com/rust-lang/rust/issues/45103#issuecomment-335622075.
If we look at the object file path in https://github.com/rust-lang/rust/issues/45103 we can see that the patch contains of few components:
```
specialization-cross-crate-defaults.stage2-x86_64-pc-windows-gnu.run-pass.libaux\specialization_cross_crate_defaults.specialization_cross_crate_defaults0.rust-cgu.o
```
=>
1. specialization-cross-crate-defaults // test name, required
2. stage2 // stage disambiguator, required
3. x86_64-pc-windows-gnu // target disambiguator, required
4. run-pass // mode disambiguator, rarely required
5. libaux // suffix, can be shortened
6. specialization_cross_crate_defaults // required, there may be several libraries in the directory
7. specialization_cross_crate_defaults0 // codegen unit name, can be shortened?
8. rust-cgu // suffix, can be shortened?
9. o // object file extension
This patch addresses items `4`, `5` and `8`.
`libaux` is shortened to `aux`, `rust-cgu` is shortened to `rcgu`, mode disambiguator is omitted unless it's necessary (for pretty-printing and debuginfo tests, see 38d26d811a)
I haven't touched names of codegen units though (`specialization_cross_crate_defaults0`).
Is it useful for them to have descriptive names including the crate name, as opposed to just `0` or `cgu0` or something?
rustc: Handle some libstd symbole exports better
Right now symbol exports, particularly in a cdylib, are handled by
assuming that `pub extern` combined with `#[no_mangle]` means "export
this". This isn't actually what we want for some symbols that the
standard library uses to implement itself, for example symbols related
to allocation. Additionally other special symbols like
`rust_eh_personallity` have no need to be exported from cdylib crate
types (only needed in dylib crate types).
This commit updates how rustc handles these special symbols by adding to
the hardcoded logic of symbols like `rust_eh_personallity` but also
adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the
export level to be considered the same as all other Rust functions
instead of looking like a C function.
The eventual goal here is to prevent functions like `__rdl_alloc` from
showing up as part of a Rust cdylib as it's just an internal
implementation detail. This then further allows such symbols to get gc'd
by the linker when creating a cdylib.
Right now symbol exports, particularly in a cdylib, are handled by
assuming that `pub extern` combined with `#[no_mangle]` means "export
this". This isn't actually what we want for some symbols that the
standard library uses to implement itself, for example symbols related
to allocation. Additionally other special symbols like
`rust_eh_personallity` have no need to be exported from cdylib crate
types (only needed in dylib crate types).
This commit updates how rustc handles these special symbols by adding to
the hardcoded logic of symbols like `rust_eh_personallity` but also
adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the
export level to be considered the same as all other Rust functions
instead of looking like a C function.
The eventual goal here is to prevent functions like `__rdl_alloc` from
showing up as part of a Rust cdylib as it's just an internal
implementation detail. This then further allows such symbols to get gc'd
by the linker when creating a cdylib.
RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute
This work-in-progress pull request contains my changes to implement [RFC 2008](https://github.com/rust-lang/rfcs/pull/2008). The related tracking issue is #44109.
As of writing, enum-related functionality is not included and there are some issues related to tuple/unit structs. Enum related tests are currently ignored.
WIP PR requested by @nikomatsakis [in Gitter](https://gitter.im/rust-impl-period/WG-compiler-middle?at=59e90e6297cedeb0482ade3e).
Add derive and doc comment capabilities to newtype_index macro
This moves `RustcDecodable` and `RustcEncodable` out of the macro definition and into the macro uses. They were conflicting with `CrateNum`'s impls of `serialize::UseSpecializedEncodable` and `serialize::UseSpecializedDecodable`, and now it's not :). `CrateNum` is now defined with the `newtype_index` macro. I also added support for doc comments on constant definitions and allowed a type to remove the pub specification on the tuple param (otherwise a LOT of code would refuse to compile for `CrateNum`). I was getting dozens of errors like this if `CrateNum` was defined as `pub struct CrateNum(pub u32)`:
```
error[E0530]: match bindings cannot shadow tuple structs
--> src/librustc/dep_graph/dep_node.rs:624:25
|
63 | use hir::def_id::{CrateNum, DefId, DefIndex, CRATE_DEF_INDEX};
| -------- a tuple struct `CrateNum` is imported here
...
624 | [] MissingLangItems(CrateNum),
| ^^^^^^^^ cannot be named the same as a tuple struct
```
I also cleaned up the formatting of the macro bodies as they were getting impossibly long. Should I go back and fix the matching rules to this style too?
I also want to see what the test results look like because `CrateNum` used to just derive `Debug`, but the `newtype_index` macro has a custom implementation. This might require further pushes.
Feel free to bikeshed on the macro language, I have no preference here.
Fix libstd compile error for windows-gnu targets without `backtrace`
This is basically an addition to #44979. Compiling `libstd` still fails when targeting `windows-gnu` with `panic = "abort"` because the items in the `...c::gnu` module are not used. They are only referenced from `backtrace_gnu.rs`, which is indirectly feature gated behind `backtrace` [here](9f3b09116b/src/libstd/sys/windows/mod.rs (L23)).
Add a nicer error message for missing in for loop, fixes#40782.
As suggested by @estebank in issue #40782, this works in the same way as #42578: if the in keyword is missing, we continue parsing the expression and if this works correctly an adapted error message is produced. Otherwise we return the old error.
A specific test case has also been added.
This is my first PR on rust-lang/rust so any feedback is very welcome.
add TerminatorKind::FalseEdges and use it in matches
impl #45184 and fixes#45043 right way.
False edges unexpectedly affects uninitialized variables analysis in MIR borrowck.
[Syntax] Implement auto trait syntax
Implements `auto trait Send {}` as a substitute for `trait Send {} impl Send for .. {}`.
See the [internals thread](https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086) for motivation. Part of #13231.
The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the `optin_builtin_traits` feature gate.
When can we remove the old syntax? Do we need to wait for a new `stage0`? We also need to formally decide for the new form (even if the keyword is not settled yet).
Observations:
- If you `auto trait Auto {}` and then `impl Auto for .. {}` that's accepted even if it's redundant.
- The new syntax is simpler internally which will allow for a net removal of code, for example well-formedness checks are effectively moved to the parser.
- Rustfmt and clippy are broken, need to fix those.
- Rustdoc just ignores it for now.
ping @petrochenkov @nikomatsakis
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
