Teach `compiletest` to ignore platform triples
The UI tests are written assuming `--remap-path-prefix` is *not used* (`remap-debuginfo` in `config.toml`). The consequence is that the error messages may include paths and snippets into the standard library. When `remap-debuginfo` is enabled, these messages change in format and structure because `rustc` will not show paths and snippets into the standard library.
This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without `remap-debuginfo`, but the `dist` artifacts are built separately with `remap-debuginfo` enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with `remap-debuginfo` enabled. This also affects developers and distributors who use `remap-debuginfo`.
To sidestep this problem, we add a way to ignore tests in specific platform triples, and update the overly broad `ignore-x86` rule in affected tests.
Address #46948, #54546, #53081.
debuginfo: Support for std::collections::Hash* in windows debuggers.
Okay, I finally needed to debug code involving a HashMap! Added support for HashSet s as well.
r? @michaelwoerister
### Local Testing
Verified these are passing locally:
```cmd
:: cmd.exe
python x.py test --stage 1 --build x86_64-pc-windows-msvc src/test/debuginfo
python x.py test --stage 1 --build i686-pc-windows-msvc src/test/debuginfo
python x.py test --stage 1 src/tools/tidy
:: MinGW MSYS2
./x.py test --stage 1 --build x86_64-pc-windows-gnu src/test/debuginfo
```
### Related Issues
* https://github.com/rust-lang/rust/issues/36503
* https://github.com/rust-lang/rust/issues/40460
* https://github.com/rust-gamedev/wg/issues/20
I based this solution on my reading of:
https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done
That post claims that there is no clean way to check for garbage pointers, and
so this PR adopts the same solution of tentatively attempting to convert a
dererence to a string, which throws a clean exception on garbage that we can
catch and recover from.
I only made the change to vec and not the other pretty printers because I wanted
to focus my effort on the simplest thing that would resolve issue #64343. In
particular, I *considered* generalizing this fix to work on the other datatypes
in the pretty-printing support library, but I don't want to invest effort in
that until after we resolve our overall debugging support strategy; see also
issues #60826 and #65564.
rustbuild: Turn down compression on msi installers
This is the same as #64615 except applied to our MSI installers. The
same fix is applied effectively bringing these installers in line with
the gz tarball installers, which are about 3x faster to produce locally
and likely much faster to produce on CI.
This is the same as #64615 except applied to our MSI installers. The
same fix is applied effectively bringing these installers in line with
the gz tarball installers, which are about 3x faster to produce locally
and likely much faster to produce on CI.
The Windows dist builders are the slowest builders right now, and the
distribution phase of them is enormously slow clocking in at around 20
minutes to build all the related installers. This commit starts to
optimize these by turning down the compression level in the `exe`
installers. These aren't super heavily used so there's no great need for
them to be so ultra-compressed, so let's dial back the compression
parameters to get closer to the rest of our xz archives. This brings the
installer in line with the gz tarball installer locally, and also brings
the compression settings on par with the rest of our xz installers.
This commit removes the `wasm_syscall` feature from the
wasm32-unknown-unknown build of the standard library. This feature was
originally intended to allow an opt-in way to interact with the
operating system in a posix-like way but it was never stabilized.
Nowadays with the advent of the `wasm32-wasi` target that should
entirely replace the intentions of the `wasm_syscall` feature.
Fix rust-lldb wrapper scripts.
Currently the `rust-lldb` wrapper provided by Rust project is broken. The error messages it produces on launch are as follows:
```
warning: ignoring unknown option: --one-line-before-file=command script import "/Users/kon/.rustup/toolchains/nightly-2019-05-02-x86_64-apple-darwin/lib/rustlib/etc/lldb_rust_formatters.py"
warning: ignoring unknown option: --one-line-before-file=type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
warning: ignoring unknown option: --one-line-before-file=type category enable Rust
(lldb) target create "target/debug/nagare"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/kon/.rustup/toolchains/nightly-2019-05-02-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/python2.7/site-packages/lldb/__init__.py", line 1481, in <module>
class SBAddress(object):
File "/Users/kon/.rustup/toolchains/nightly-2019-05-02-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/python2.7/site-packages/lldb/__init__.py", line 1647, in SBAddress
__swig_getmethods__["module"] = GetModule
NameError: name '__swig_getmethods__' is not defined
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
...etc.
```
The errors stem from two regressions: one caused by an LLVM upgrade and one caused by unintended upgrade to SWIG 4.0 (SWIG is a wrapper generator that is used to generate Python bindings for LLVM and LLDB.)
(Edit: found the exact dates) The SWIG breakage happened because of a Homebrew version upgrade on `nightly-2019-05-01-x86_64-apple-darwin` and the LLVM breakage happened on `nightly-2019-01-27-x86_64-apple-darwin` (likely to have been caused by https://github.com/rust-lang/rust/pull/57675 ).
The fix is to update the LLVM parameter syntax and to "downgrade" to SWIG 3.0.x. SWIG 3.0.x is not going to be supported by Homebrew forever, but should be good for now, until LLDB upgrades to support SWIG 4.0.0. Here's some more info about Homebrew support: https://github.com/Homebrew/homebrew-core/pull/39929 & https://github.com/Homebrew/homebrew-core/pull/40882 I'm going to send a bug & fix to LLDB about SWIG 4.0.0 to get the situation fixed in the future.
It would be good to also backport this to beta, since it's such a small change, and will fix an obvious regression.
Updated to handle these changes:
- `core::ptr::*` lost their `__0` elements and are just plain pointers
- `core::ptr::*` probably shouldn't dereference in `DisplayString` s
- `VecDeque` and `Vec` use `core::ptr::*` s
- `VecDeque` and `LinkedList` moved modules again.
Retested - still working fine, left alone:
- `String`, `&str`, `Option`
[rust-gdb] relax the GDB version regex
The pretty-printer script is checking `gdb.VERSION` to see if it's at
least 8.1 for some features. With `re.match`, it will only find the
version at the beginning of that string, but in Fedora the string is
something like "Fedora 8.2-5.fc29". Using `re.search` instead will find
the first location that matches anywhere, so it will find my 8.2.
The pretty-printer script is checking `gdb.VERSION` to see if it's at
least 8.1 for some features. With `re.match`, it will only find the
version at the beginning of that string, but in Fedora the string is
something like "Fedora 8.2-5.fc29". Using `re.search` instead will find
the first location that matches anywhere, so it will find my 8.2.
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
use utf-8 throughout htmldocck
This commit improves compatibility with Python 3, which already uses
Unicode throughout.
It also fixes a subtle incompatibility stemming from the use of
`entitydefs`, which contains replacement text _encoded in latin-1_ for
HTML entities. When using Python 3, this would cause `0xa0` to be
incorrectly added to the element tree.
This meant that there was a rustdoc test that would pass under Python 2
but fail under Python 3, due to an incorrect regex match against the
non-breaking space character. This commit triggers that failure in both
versions, and also fixes it.
This commit improves compatibility with Python 3, which already uses
Unicode throughout.
It also fixes a subtle incompatibility stemming from the use of
`entitydefs`, which contains replacement text _encoded in latin-1_ for
HTML entities. When using Python 3, this would cause `0xa0` to be
incorrectly added to the element tree.
This meant that there was a rustdoc test that would pass under Python 2
but fail under Python 3, due to an incorrect regex match against the
non-breaking space character. This commit triggers that failure in both
versions, and also fixes it.
gdb versions before 8.1 have a bug that prevents the BTreeSet and
BTreeMap pretty-printers from working. This patch disables the test
on those versions, and also disables the pretty-printers there as
well.
Closes#56730
Fix BTreeSet and BTreeMap gdb pretty-printers
The BTreeSet and BTreeMap gdb pretty-printers did not take the node
structure into account, and consequently only worked for shallow sets.
This fixes the problem by iterating over child nodes when needed.
This patch avoids the current approach of implementing some of the
value manipulations in debugger-indepdendent code. This was done for
convenience: a type lookup was needed for the first time, and there
currently are no lldb formatters for these types.
Closes#55771
Disable some pretty-printers when gdb is rust-enabled
A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after #54004, the pretty-printers
can't handle enums at all). This patch disables these pretty-printers
when gdb is rust-enabled.
The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.
The BTreeSet and BTreeMap gdb pretty-printers did not take the node
structure into account, and consequently only worked for shallow sets.
This fixes the problem by iterating over child nodes when needed.
This patch avoids the current approach of implementing some of the
value manipulations in debugger-indepdendent code. This was done for
convenience: a type lookup was needed for the first time, and there
currently are no lldb formatters for these types.
Closes#55771
A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after #54004, the pretty-printers
can't handle enums at all). This patch disables these pretty-printers
when gdb is rust-enabled.
The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.
