Rollup merge of #76088 - hbina:add_example, r=LukasKalbertodt
Add more examples to lexicographic cmp on Iterators.
Given two arrays of T1 and T2, the most important rule of lexicographical comparison is that two arrays
of equal length will be compared until the first difference occured.
The examples provided only focuses on the second rule that says that the
shorter array will be filled with some T2 that is less than every T1.
Which is only possible because of the first rule.
Rollup merge of #76074 - richkadel:llvm-coverage-map-gen-6b.5.1, r=wesleywiser
Add new `-Z dump-mir-spanview` option
Similar to `-Z dump-mir-graphviz`, this adds the option to write
HTML+CSS files that allow users to analyze the spans associated with MIR
elements (by individual statement, just terminator, or overall basic
block).
This PR was split out from PR #76004, and exposes an API for spanview
HTML+CSS files that is also used to analyze code regions chosen for
coverage instrumentation (in a follow-on PR).
Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage
instrumentation
Auto merge of #76010 - Aaron1011:fix/cfg-generic-param, r=petrochenkov
Run cfg-stripping on generic parameters before invoking derive macros
Fixes #75930
This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
Auto merge of #75529 - bugadani:bounds-check, r=nagisa
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.
Auto merge of #76071 - khyperia:configurable_to_immediate, r=eddyb
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.
Rich Kadel [Sat, 29 Aug 2020 17:55:46 +0000 (10:55 -0700)]
Add new `-Z dump-mir-spanview` option
Similar to `-Z dump-mir-graphviz`, this adds the option to write
HTML+CSS files that allow users to analyze the spans associated with MIR
elements (by individual statement, just terminator, or overall basic
block).
This PR was split out from PR #76004, and exposes an API for spanview
HTML+CSS files that is also used to analyze code regions chosen for
coverage instrumentation (in a follow-on PR).
Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage
instrumentation
Auto merge of #76186 - tmandry:rollup-49nliiy, r=tmandry
Rollup of 12 pull requests
Successful merges:
- #75945 (Use `env::func()`, not 'the function env::func' in docs for std::env)
- #76002 (Fix `-Z instrument-coverage` on MSVC)
- #76003 (Adds two source span utility functions used in source-based coverage)
- #76059 (Clean up E0764)
- #76103 (Clean up E0769)
- #76139 (Make `cow_is_borrowed` methods const)
- #76154 (Fix rustdoc strings indentation)
- #76161 (Remove notrust in rustc_middle)
- #76163 (README: Adjust Linux and macOS support platform and architecture)
- #76166 (Make `StringReader` private)
- #76172 (Revert #75463)
- #76178 (Update expect-test to 1.0)
Rollup merge of #76178 - matklad:et, r=Mark-Simulacrum
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.
Rollup merge of #76003 - richkadel:llvm-coverage-map-gen-6b.4, r=wesleywiser
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).
Rollup merge of #76002 - richkadel:llvm-coverage-map-gen-6b.3, r=tmandry
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).
Rich Kadel [Thu, 27 Aug 2020 20:58:01 +0000 (13:58 -0700)]
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).
Rich Kadel [Thu, 27 Aug 2020 19:53:43 +0000 (12:53 -0700)]
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.
bors [Mon, 31 Aug 2020 21:57:35 +0000 (21:57 +0000)]
Auto merge of #76174 - ehuss:update-cargo, r=ehuss
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)
bors [Mon, 31 Aug 2020 20:03:33 +0000 (20:03 +0000)]
Auto merge of #75979 - lzutao:seprate-tests, r=Mark-Simulacrum
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.
Aleksey Kladov [Mon, 31 Aug 2020 19:04:09 +0000 (21:04 +0200)]
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.
bors [Mon, 31 Aug 2020 18:04:29 +0000 (18:04 +0000)]
Auto merge of #76030 - davidtwco:fewer-names-llvm-type-of, r=eddyb
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!
Aleksey Kladov [Sat, 29 Aug 2020 12:29:23 +0000 (14:29 +0200)]
Avoid StringReader when checking code blocks for syntax errors
`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.
bors [Mon, 31 Aug 2020 13:30:13 +0000 (13:30 +0000)]
Auto merge of #76159 - matklad:rollup-8jydjg3, r=matklad
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)
Aleksey Kladov [Mon, 31 Aug 2020 13:22:43 +0000 (15:22 +0200)]
Rollup merge of #76115 - calebcartwright:parser-fn-visibility, r=matklad
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`
Aleksey Kladov [Mon, 31 Aug 2020 10:51:55 +0000 (12:51 +0200)]
Rollup merge of #76134 - CDirkx:patch-1, r=nagisa
Update MinGW instructions to include ninja
Rust now requires `ninja` to build, so the MinGW build instructions are updated to reflect this.
Like for `python` and `cmake`, the `mingw-w64-x86_64-ninja` package should be used. The default package from the `msys2` subsystem doesn't handle paths correctly on windows.
Aleksey Kladov [Mon, 31 Aug 2020 10:51:46 +0000 (12:51 +0200)]
Rollup merge of #76052 - aszenz:GH-66816_removes_disable_attribute_before_return, r=GuillaumeGomez
GH-66816: Remove disable attr before return
Passing --disable-per-crate-search removes the create search inputs so moved code around so that the search input is enabled
first before the function returns.
David Wood [Fri, 28 Aug 2020 15:24:52 +0000 (16:24 +0100)]
cg_llvm: `fewer_names` in `uncached_llvm_type`
This commit 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.
bors [Mon, 31 Aug 2020 09:09:37 +0000 (09:09 +0000)]
Auto merge of #75932 - Amjad50:intra-doc-core-slice, r=jyn514
Use intra-doc links for `core/src/slice.mod.rs`
partial help in #75080
r? @jyn514
- most are using primitive types links, which cannot be used with intra links at the moment
- also `std` cannot be referenced in any link, `std::ptr::NonNull` and `std::slice` could not be referenced
bors [Mon, 31 Aug 2020 05:32:54 +0000 (05:32 +0000)]
Auto merge of #76027 - davidtwco:issue-61139-remove-obsolete-pretty-printer, r=eddyb
ty: remove obsolete pretty printer
Fixes #61139.
This PR removes the obsolete printer and replaces all uses of it with `FmtPrinter`. Of the replaced uses, all but one use was in `debug!` logging, two cases were notable:
- `MonoItem::to_string` is used in `-Z print-mono-items` and therefore affects the output of all codegen-units tests (which have been updated).
- `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs` with `LLVMStructCreateNamed` and that'll now get different values, but nothing will break as a result of this.
bors [Mon, 31 Aug 2020 03:19:05 +0000 (03:19 +0000)]
Auto merge of #75082 - Aaron1011:feature/proc-macro-backtrace, r=petrochenkov
Add `-Z proc-macro-backtrace` to allow showing proc-macro panics
Fixes #75050
Previously, we would unconditionally suppress the panic hook during
proc-macro execution. This commit adds a new flag
`-Z proc-macro-backtrace`, which allows running the panic hook for
easier debugging.
Aaron Hill [Mon, 31 Aug 2020 02:17:24 +0000 (22:17 -0400)]
Add `-Z proc-macro-backtrace` to allow showing proc-macro panics
Fixes #75050
Previously, we would unconditionally suppress the panic hook during
proc-macro execution. This commit adds a new flag
-Z proc-macro-backtrace, which allows running the panic hook for
easier debugging.
CDirkx [Sun, 30 Aug 2020 23:22:25 +0000 (01:22 +0200)]
Update MinGW instructions to include ninja
Added the `mingw-w64-x86_64-ninja` package to the build guide for MinGW, as well as a note not to use the `ninja` package from the `msys2` subsystem (doesn't handle paths correctly on windows).
bors [Sun, 30 Aug 2020 21:03:06 +0000 (21:03 +0000)]
Auto merge of #75779 - scileo:fix-issue-75492, r=petrochenkov
Improve error message when typo is made in format!
The expansion of the format! built-in macro is roughly done in two steps:
- the format expression is parsed, the arguments are parsed,
- the format expression is checked to be a string literal, code is expanded.
The problem is that the expression parser can eat too much tokens, which invalidates the parsing of the next format arguments. As the format expression check happens next, the error emitted concerns the format arguments, whereas the problem is about the format expression.
This PR contains two commits. The first one actually checks that the formatting expression is a string literal before raising any error about the formatting arguments, and the second one contains some simple heuristics which allow to suggest, when the format expression is followed by a dot instead of a comma, to suggest to replace the dot with a comma.
This pull request should fix #75492.
Note: this is my first non-doc contribution to the rust ecosystem. Feel free to make any comment about my code, or whatever. I'll be very happy to fix it :)
Sebastian Dröge [Fri, 28 Aug 2020 05:55:41 +0000 (08:55 +0300)]
Add (non-public) slice::split_at_unchecked() and split_at_mut_unchecked()
These are unsafe variants of the non-unchecked functions and don't do
any bounds checking.
For the time being these are not public and only a preparation for the
following commit. Making it public and stabilization can follow later
and be discussed in https://github.com/rust-lang/rust/issues/76014 .
Sasha [Fri, 28 Aug 2020 21:04:42 +0000 (23:04 +0200)]
Use string literal directly when available in format
Previous implementation used the `Parser::parse_expr` function in order
to extract the format expression. If the first comma following the
format expression was mistakenly replaced with a dot, then the next
format expression was eaten by the function, because it looked as a
syntactically valid expression, which resulted in incorrectly spanned
error messages.
The way the format expression is exctracted is changed: we first look at
the first available token in the first argument supplied to the
`format!` macro call. If it is a string literal, then it is promoted as
a format expression immediatly, otherwise we fall back to the original
`parse_expr`-related method.
This allows us to ensure that the parser won't consume too much tokens
when a typo is made.
A test has been created so that it is ensured that the issue is properly
fixed.
David Wood [Fri, 28 Aug 2020 13:31:03 +0000 (14:31 +0100)]
ty: remove obsolete printer
This commit removes the obsolete printer and replaces all uses of it
with `FmtPrinter`. Of the replaced uses, all but one use was in `debug!`
logging, two cases were notable:
- `MonoItem::to_string` is used in `-Z print-mono-items` and therefore
affects the output of all codegen-units tests.
- `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs`
with `LLVMStructCreateNamed` and that'll now get different values, but
this should result in no functional change.
Aaron Hill [Fri, 28 Aug 2020 03:17:40 +0000 (23:17 -0400)]
Run cfg-stripping on generic parameters before invoking derive macros
Fixes #75930
This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
bors [Sun, 30 Aug 2020 15:57:57 +0000 (15:57 +0000)]
Auto merge of #74862 - mark-i-m:mv-compiler, r=petrochenkov
Move almost all compiler crates to compiler/
This PR implements https://github.com/rust-lang/compiler-team/issues/336 and moves all `rustc_*` crates from `src` to the new `compiler` directory.
`librustc_foo` directories are renamed to `rustc_foo`.
`src` directories are introduced inside `rustc_*` directories to mirror the scheme already use for `library` crates.
projects / rust.git / log