This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes#42808
RLS on beta
Reverts the RLS backout commit, updates the RLS to the beta branch (which includes a relative path dep for Cargo and sets the version to 0.121, plus fixes a bug I was having running tests on the beta branch), and backports #44141 (renaming rls component to rls-preview).
r? @alexcrichton
[beta] Track closure signatures & kinds in freshened types
This allows caching closure signatures and kinds in the normal selection
and evaluation caches, and fixes the exponential worst-case in
@remram44's example, which is a part of #43787.
This improvement is complenentary to #43999 - they fix different cases.
This is the pre-generators variation of #43938, cloned for beta.
This allows caching closure signatures and kinds in the normal selection
and evaluation caches, and fixes the exponential worst-case in
@remram44's example, which is a part of #43787.
This improvement is complenentary to #43999 - they fix different cases.
ci: Remove the need for `dumb-init`
Newer versions of Docker have a `--init` argument which spawns an init process
in the container, which we should be able to use everywhere now.
Fixes issue #43205: ICE in Rvalue::Len evaluation.
- fixes evaluation of array length for zero-sized type referenced by rvalue operand.
- adds test to verify fix.
*Cause of the issue*.
Zero-sized aggregates are handled as operands, not lvalues. Therefore while visiting `Assign` statement by `LocalAnalyser`, `mark_as_lvalue()` is not called for related `Local`. This behaviour is controlled by `rvalue_creates_operand()` method.
As result it causes error later, when rvalue operand is evaluated in `trans_rvalue_operand()` while handling `Rvalue::Len` case. Array length evaluation invokes `trans_lvalue()` which expects referenced `Local` to be value, not operand.
*How it is fixed*.
In certain cases result of `Rvalue::Len` can be evaluated without calling
`trans_lvalue()`. Method `evaluate_array_len()` is introduced to handle length
evaluation for zero-sized types referenced by Locals.
*Some concerns*.
- `trans_lvalue()` has two other entry points in `rvalue.rs`: it is invoked while handling `Rvalue::Ref` and `Rvalue::Discriminant`. There is a chance those may produce the same issue, but I've failed to write a specific test that leads to this.
- `evaluate_array_len()` performs the same check (matches lvalue and `Local`), which is performed again in `trans_lvalue()`. Without changing `trans_lvalue()` signature to make it aware that caller deals with rvalue, it seems there is no cheap solution to avoid this check.
Make unused-extern-crate warn-by-default
Apart from enabling the lint, this pull request also removes existing unused crates in the codebase, and fix some amount of false positives on crates with special purposes.
Now that all false positive issues are closed, it should be possible to make it available to wider users.
Quote:
> Now that macro modularization is implemented, this is true today! *https://github.com/rust-lang/rust/issues/30849#issuecomment-286573218*
Concerns: can break some `#[deny(warnings)]`.
Close#42591
Update cargo
Should permit https://github.com/rust-lang/rust/pull/41991 to move forward. I think it's best to land this as a separate patch and rebase that, though.
r? @alexcrichton
Add test for wrong code generation for HashSet creation on arm cpu
This is test for #42918.
To reproduce bug you need machine with arm cpu and compile with optimization.
I tried with rustc 1.19.0-nightly (3d5b8c626 2017-06-09),
if compile test with -C opt-level=3 for target=arm-linux-androideabi
and run on "Qualcomm MSM 8974 arm cpu" then assert fails,
if compile and run with -C opt-level=2 it gives segmentation fault.
So I add `compile-flags: -O`.
With rustc 1.19.0 (0ade33941 2017-07-17) all works fine.
Closes#42918
rustbuild: Automatically enable Ninja on MSVC
Discovered in #43767 it turns out the default MSBuild generator in CMake for
whatever reason isn't supporting many of the configuration options we give to
LLVM. To improve the contributor experience automatically enable Ninja if we
find it to ensure that "flavorful" configurations of LLVM work by default in
more situations.
Closes#43767
Fix destruction extent lookup during HIR -> HAIR translation
My method for finding the destruction extent, if any, from cbed41a174 (in #39409), was buggy in that it sometimes failed to find an extent that was nonetheless present.
This fixes that, and is cleaner code to boot.
Fix#43457
haiku/librustc_back: Remove incorrect no_integrated_as
* Makes rust bootstrap incorrectly search for xxx.s vs xxx.0.s
* Not needed or incorrect fix for another issue.
Fix inconsistent doc headings
This fixes headings reading "Unsafety" and "Example", they should be "Safety" and "Examples" according to RFC 1574.
r? @steveklabnik
Remove duplicates in rustdoc
Fixes#43934.
Two things however:
1. I'm not happy with the current check. It seems completely overkill and unsatisfying.
2. I have no idea how to test if there is only one element and not two.
r? @rust-lang/docs
Fix a byte/char confusion issue in the error emitter
Fixes#44078. Fixes#44023.
The start_col member is given in chars, while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
rustc: Start moving toward "try_get is a bug" for incremental
This PR is an effort to burn down some of the work items on #42633. The basic change here was to leave the `try_get` function exposed but have it return a `DiagnosticBuilder` instead of a `CycleError`. This means that it should be a compiler bug to *not* handle the error as dropping a diagnostic should result in a complier panic.
After that change it was then necessary to update the compiler's callsites of `try_get` to handle the error coming out. These were handled as:
* The `sized_constraint` and `needs_drop_raw` checks take the diagnostic and defer it as a compiler bug. This was a new piece of functionality added to the error handling infrastructure, and the idea is that for both these checks a "real" compiler error should be emitted elsewhere, so it's only a bug if we don't actually emit the complier error elsewhere.
* MIR inlining was updated to just ignore the diagnostic. This is being tracked by https://github.com/rust-lang/rust/issues/43542 which sounded like it either already had some work underway or was planning to change regardless.
* The final case, `item_path`, is still sort of up for debate. At the time of this writing this PR simply removes the invocations of `try_get` there, assuming that the query will always succeed. This turns out to be true for the test suite anyway! It sounds like, though, that this logic was intended to assist in "weird" situations like `RUST_LOG` where debug implementations can trigger at any time. This PR would therefore, however, break those implementations.
I'm unfortunately sort of out of ideas on how to handle `item_path`, but other thoughts would be welcome!
Closes#42633
This is test for #42918.
To reproduce bug you need machine with arm cpu and compile with optimization.
I tried with rustc 1.19.0-nightly (3d5b8c626 2017-06-09),
if compile test with -C opt-level=3 for target=arm-linux-androideabi
and run on "Qualcomm MSM 8974 arm cpu" then assert fails,
if compile and run with -C opt-level=2 it gives segmentation fault.
So I add `compile-flags: -O`.
With rustc 1.19.0 (0ade33941 2017-07-17) all works fine.
Closes#42918
