| Age | Commit message (Collapse) | Author | Lines |
|
Stablize `non-ascii-idents`
This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).
r? `@Manishearth`
|
|
The issue was that the resulting debuginfo was too complex for LLVM to
translate into CodeView records correctly. As a result, it simply
ignored the debuginfo which meant Windows debuggers could not display
any closed over variables when stepping inside a closure.
This fixes that by spilling additional variables to the stack so that
the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and
LLVM can generate the correct CV records.
|
|
|
|
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
|
|
|
|
NatVis files describe how to display types in some Windows debuggers,
such as Visual Studio, WinDbg, and VS Code.
This commit makes several improvements:
* Adds visualizers for Rc<T>, Weak<T>, and Arc<T>.
* Changes [size] to [len], for consistency with the Rust API.
Visualizers often use [size] to mirror the size() method on C++ STL
collections.
* Several visualizers used the PVOID and ULONG typedefs. These are part
of the Windows API; they are not guaranteed to always be defined in a
pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to
`unsigned long`.
* Cosmetic change: Removed {} braces around the visualized display
for `Option` types. They now display simply as `Some(value)` or
`None`, which reflects what is written in source code.
* The visualizer for `alloc::string::String` makes assumptions about
the layout of `String` (it casts `String*` to another type), rather
than using symbolic expressions. This commit changes the visualizer
so that it simply uses symbolic expressions to access the string
data and string length.
|
|
Add support for custom allocators in `Vec`
This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections.
r? `@Amanieu`
This pull request requires a crater run.
### Prior work:
- #71873: Crater-test to solve rust-lang/wg-allocators#1
- [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate
|
|
BTreeMap: replace Root with NodeRef<Owned, ...>
`NodeRef<marker::Owned, …>` already exists as a representation of root nodes, and it makes more sense to alias `Root` to that than to reuse the space-efficient `BoxedNode` that is oblivious to height, where height is required.
r? `@Mark-Simulacrum`
|
|
|
|
|
|
On macOS the test is flaky and sometimes fails,
sometimes succeeds on CI.
|
|
|
|
|
|
cdb chokes on the cast and reports "Unable to find type 'tuple<u64,u64> *' for cast."
|
|
This reverts commit 25670749b44a9c7a4cfd3fbf780bbe3344a9a6c5.
This commit does not actually fix the problem. It merely removes the name of
the argument from the LLVM output. Even without the name, Rust codegen still
spills the (nameless) variable onto the stack which is the root cause. The root
cause is solved in the next commit.
|
|
Don't call a function in function-arguments-naked.rs
Fixes #75096
It's U.B. to use anything other than inline assmebling in a naked
function. Fortunately, the `#break` directive works fine without
anything in the function body.
|
|
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
|
|
We need to use inline assembly, which is inherently platform-specific.
|
|
|
|
Fixes #75096
It's U.B. to use anything other than inline assmebling in a naked
function. Fortunately, the `#break` directive works fine without
anything in the function body.
|
|
It requires loading pretty-printers, but GDB doesn't load them on Windows
|
|
A function that has no prologue cannot be reasonably expected to support
debuginfo. In fact, the existing code (before this patch) would generate
invalid instructions that caused crashes. We can solve this easily by
just not emitting the debuginfo in this case.
Fixes https://github.com/rust-lang/rust/issues/42779
cc https://github.com/rust-lang/rust/issues/32408
|
|
|
|
- Mangles (T0, T1) as tuple<T0, T1>, possibly unblocking rust-lang/rust#70052 "Update hashbrown to 0.8.0"
- Prettifies Rust tuples similar to VS2017's std::tuple
- Improves debuginfo test coverage
|
|
Replace old GDB and LLDB pretty-printers with new ones
which were originally written for IntelliJ Rust.
New LLDB pretty-printers support synthetic children.
New GDB/LLDB pretty-printers support all Rust types
supported by old pretty-printers, and also support:
Rc, Arc, Cell, Ref, RefCell, RefMut, HashMap, HashSet.
|
|
|
|
LLVM 8 was released on March 20, 2019, over a year ago.
|
|
|
|
|
|
|
|
|
|
https://sourceware.org/bugzilla/show_bug.cgi?id=22236
|
|
|
|
|
|
These are no longer relevant, as our minimum supported version
is LLVM 7.
|
|
|
|
|
|
|
|
LLDB's expression parser can't unambiguously resolve local variables in
some cases, as described in #47938. Work around this by using names that
don't shadow direct submodules of `core`.
|
|
|
|
Closure types have been moved to the namespace where they
are defined, and both closure and generator type names now
include the disambiguator.
This fixes an exception when lldb prints nested closures.
Fixes #57822
|
|
|
|
regressions, like those fixed in #60687.
Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files.
While this only tests CDB, that test coverage should help for all of them.
CHANGES
src\bootstrap
- test.rs: Run CDB debuginfo tests on MSVC targets
src\test\debuginfo
- issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?)
- pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests.
- should-fail.rs: Add CDB tests.
src\tools\compiletest:
- Added "-cdb" option
- Added Mode::DebugInfoCdb ("debuginfo-cdb")
- Added run_debuginfo_cdb_test[_no_opt]
- Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means.
- Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe"
- Ignore CDB tests if CDB not found.
ISSUES
- `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%`
- `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist)
- DSTs (array/string slices) which work in VS & VS Code fail in CDB.
- I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations.
REFERENCE
CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
Installing just "Debugging Tools for Windows" is sufficient.
CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here:
https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227
CDB commands and command line reference:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|