Move ninja requirements to a dynamic check, when actually building
It isn't practical to determine whether we'll build LLVM very early in the
pipeline, so move the ninja checking to a dynamic check.
r? @pietroalbini -- this should fix nightlies
Eliminate some other bound checks when index comes from an enum
#36962 introduced an assumption for the upper limit of the enum's value. This PR adds an assumption to the lower value as well.
I've modified the original codegen test to show that derived (in that case, adding 1) values also don't generate bounds checks.
However, this test is actually carefully crafted to not hit a bug: if the enum's variants are modified to 1 and 2 instead of 2 and 3, the test fails by adding a bounds check. I suppose this is an LLVM issue and #75525, while not exactly in this context should be tracking it.
I'm not at all confident if this patch can be accepted, or even if it _should_ be accepted in this state. But I'm curious about what others think :)
~Improves~ Should improve #13926 but does not close it because it's not exactly predictable, where bounds checks may pop up against the assumptions.
Make to_immediate/from_immediate configurable by backends
`librustc_codegen_ssa` has the concept of an immediate vs. memory type, and `librustc_codegen_llvm` uses this distinction to implement `bool`s being `i8` in memory, and `i1` in immediate contexts. However, some of that implementation leaked into `codegen_ssa` when converting to/from immediate values. So, move those methods into builder traits, so that behavior can be configured by backends.
This is useful if a backend is able to keep bools as bools, or, needs to do more trickery than just bools to bytes.
(Note that there's already a large amount of things abstracted with "immediate types" - this is just bringing this particular thing in line to be abstracted as well)
---
Pinging @eddyb since that's who I was talking about this change with when they suggested I submit a PR.
rename get_{ref, mut} to assume_init_{ref,mut} in Maybeuninit
References #63568
Rework with comments addressed from #66174
Have replaced most of the occurrences I've found, hopefully didn't miss out anything
r? @RalfJung
(thanks @danielhenrymantilla for the initial work on this)
Update expect-test to 1.0
The only change is that `expect_file` now uses path relative to the
current file (same as `include!`). Before, it used paths relative to
the workspace root, which makes no sense.
Make `cow_is_borrowed` methods const
Constify the following methods of `alloc::borrow::Cow`:
- `is_borrowed`
- `is_owned`
Analogous to the const methods `is_some` and `is_none` for Option, and `is_ok` and `is_err` for Result.
These methods are still unstable under `cow_is_borrowed`.
Possible because of #49146 (Allow if and match in constants).
Tracking issue: #65143
Adds two source span utility functions used in source-based coverage
`span.is_empty()` - returns true if `lo()` and `hi()` are equal. This is
not only a convenience, but makes it clear that a `Span` can be empty
(that is, retrieving the source for an empty `Span` will return an empty
string), and codifies the (otherwise undocumented--in the rustc_span
package, at least) fact that `Span` is a half-open interval (where
`hi()` is the open end).
`source_map.lookup_file_span()` - returns an enclosing `Span`
representing the start and end positions of the file enclosing the given
`BytePos`. This gives developers a clear way to quickly determine if any
any other `BytePos` or `Span` is also from the same file (for example,
by simply calling `file_span.contains(span)`).
This results in much simpler code and is much more runtime efficient
compared with the obvious alternative: calling `source_map.lookup_line()`
for any two `Span`'s byte positions, handle both arms of the `Result`
(both contain the file), and then compare files. It is also more
efficient than the non-public method `lookup_source_file_idx()` for each
`BytePos`, because, while comparing the internal source file indexes
would be efficient, looking up the source file index for every `BytePos`
or `Span` to be compared requires a binary search (worst case
performance being O(log n) for every lookup).
`source_map.lookup_file_span()` performs the binary search only once, to
get the `file_span` result that can be used to compare to any number of
other `BytePos` or `Span` values and those comparisons are always O(1).
This PR was split out from PR #75828 .
r? @tmandry
FYI: @wesleywiser
Fix `-Z instrument-coverage` on MSVC
Found that `-C link-dead-code` (which was enabled automatically
under `-Z instrument-coverage`) was causing the linking error that
resulted in segmentation faults in coverage instrumented binaries. Link
dead code is now disabled under MSVC, allowing `-Z instrument-coverage`
to be enabled under MSVC for the first time.
More details are included in Issue #76038 .
Note this PR makes it possible to support `Z instrument-coverage` but
does not enable instrument coverage for MSVC in existing tests. It will be
enabled in another PR to follow this one (both PRs coming from original
PR #75828).
r? @tmandry
FYI: @wesleywiser
`span.is_empty()` - returns true if `lo()` and `hi()` are equal. This is
not only a convenience, but makes it clear that a `Span` can be empty
(that is, retrieving the source for an empty `Span` will return an empty
string), and codifies the (otherwise undocumented--in the rustc_span
package, at least) fact that `Span` is a half-open interval (where
`hi()` is the open end).
`source_map.lookup_file_span()` - returns an enclosing `Span`
representing the start and end positions of the file enclosing the given
`BytePos`. This gives developers a clear way to quickly determine if any
any other `BytePos` or `Span` is also from the same file (for example,
by simply calling `file_span.contains(span)`).
This results in much simpler code and is much more runtime efficient
compared with the obvious alternative: calling `source_map.lookup_line()`
for any two `Span`'s byte positions, handle both arms of the `Result`
(both contain the file), and then compare files. It is also more
efficient than the non-public method `lookup_source_file_idx()` for each
`BytePos`, because, while comparing the internal source file indexes
would be efficient, looking up the source file index for every `BytePos`
or `Span` to be compared requires a binary search (worst case
performance being O(log n) for every lookup).
`source_map.lookup_file_span()` performs the binary search only once, to
get the `file_span` result that can be used to compare to any number of
other `BytePos` or `Span` values and those comparisons are always O(1).
Found that -C link-dead-code (which was enabled automatically
under -Z instrument-coverage) was causing the linking error that
resulted in segmentation faults in coverage instrumented binaries. Link
dead code is now disabled under MSVC, allowing `-Z instrument-coverage`
to be enabled under MSVC for the first time.
More details are included in Issue #76038.
(This PR was broken out from PR #75828)
Update cargo
8 commits in 51b66125ba97d2906f461b3f4e0408f206299bb6..126907a7cfccbe93778530e6a6bbaa3adb6c515c
2020-08-19 20:22:52 +0000 to 2020-08-31 20:42:11 +0000
- Fix flakiness in close_output test (rust-lang/cargo#8668)
- Reload unstable table from config file in `reload_rooted_at` (rust-lang/cargo#8656)
- Bump to 0.49.0, update changelog (rust-lang/cargo#8659)
- Fix LTO with doctests. (rust-lang/cargo#8657)
- Add spaces after -C and -Z flags for consistency (rust-lang/cargo#8648)
- Fix cache_messages::rustdoc test broken on beta. (rust-lang/cargo#8653)
- fix: remove unnecessary allocations (rust-lang/cargo#8641)
- Fixed a spelling and some clippy warnings (rust-lang/cargo#8637)
Move `#[cfg(test)]` modules into separate files to save recompiling the `std` crate
Implements an accepted proposal: https://github.com/rust-lang/compiler-team/issues/344
Some notes for reviewers:
* `mod tests` nested in `mod foo` in `mod bar`, I move `foo` to a new file, `tests` is a new file in foo: For example library/std/src/sys/sgx/abi/tls.rs
* `mod test` (not `mod tests`) also is moved.
* `mod benches` are moved.
* `mod tests` is placed before any `use` statements: The topic is discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Code.20Style.20process
* Some files in cloudabi was changed too. But I notice copyright banners in those files, should we ping cloudabi people?
* I formatted files after moving tests around. I think that may make it easier to review :p .
* Some files don't need `ignore-tidy-filelength` anymore.
The only change is that `expect_file` now uses path relative to the
current file (same as `include!`). Before, it used paths relative to
the workspace root, which makes no sense.
cg_llvm: `fewer_names` in `uncached_llvm_type`
This PR changes `uncached_llvm_type` so that a named struct type (with an empty name) is always created when the `fewer_names` option is enabled. By skipping the generation of names, we can improve perf. Giving `LLVMStructCreateNamed` an empty name works because LLVM will perform random renames to avoid collisions. Needs a perf run!
cc @eddyb (whom I've discussed this with)
Get rid of bounds check in slice::chunks_exact() and related function…
…s during construction
LLVM can't figure out in
let rem = self.len() % chunk_size;
let len = self.len() - rem;
let (fst, snd) = self.split_at(len);
and
let rem = self.len() % chunk_size;
let (fst, snd) = self.split_at(rem);
that the index passed to split_at() is smaller than the slice length and
adds a bounds check plus panic for it.
Apart from removing the overhead of the bounds check this also allows
LLVM to optimize code around the ChunksExact iterator better.
`parse_stream_from_source_str` is a more stable API to convert a
string into a bunch of tokens, and it also catches errors about
mismatched parenthesis.
Rollup of 5 pull requests
Successful merges:
- #75938 (Added some `min_const_generics` revisions into `const_generics` tests)
- #76050 (Remove unused function)
- #76075 (datastructures: replace `once_cell` crate with an impl from std)
- #76115 (Restore public visibility on some parsing functions for rustfmt)
- #76127 (rustbuild: Remove one LLD workaround)
Failed merges:
r? @ghost
Restore public visibility on some parsing functions for rustfmt
In #74826 the visibility of several parsing functions was reduced. However, rustfmt is an external consumer of some of these functions as well and needs the visibility to be public, similar to other elements in rustc_parse such as `parse_ident`
db534b3ac2/src/librustc_parse/parser/mod.rs (L433-L436)
