mirror of
https://github.com/rust-lang/rust.git
synced 2026-05-15 20:45:45 +03:00
bors
67ed30cd5e
Who would have thought that namespaces are such a can of worms `:P` This is mostly because of some GDB idiosyncrasies (does not use namespace information but linkage-name attributes for displaying items contained in namespaces, also cannot handle functions lexically nested within functions), monomorphization, and information about external items only available from metadata. This pull request tries to tackle the problem anyway: * The `DW_AT_linkage_name` for functions is generated just to make GDB display a proper namespace-enabled function name. To this end, a pseudo-mangled name is generated, not corresponding to the real linkage name. This approach shows some success and could be extended to make GDB also show proper parameter types. * As GDB won't accept subprogram DIEs nested within other subprogram DIEs, the `debuginfo` module now generates a *companion namespace* for each functions (iff needed). A function `fn abc()` will get a companion namespace with name `abc()`, which contains all items (modules, types, functions) declared within the functions scope. The real, proper solution, in my opinion, would be to faithfully reflect the program's lexical structure within DWARF (which allows arbitrary nesting of DIEs, afaik), but I am not sure LLVM's source level debugging implementation would like that and I am pretty sure GDB won't support this in the foreseeable future. * Monomorphization leads to functions and companion namespaces like `somelib::some_func<int, float>()::some_other_function<bool, bool, bool>()`, which I think is the desired behaviour. There is some design space here, however. Maybe you people prefer `somelib::some_func()::some_other_function<bool, bool, bool>()` or `somelib::some_func()::some_other_function::<int, float, bool, bool, bool>()`. The solution will work for now but there are a few things on my 'far future wish list': * A real specification somewhere, what language constructs are mapped to what DWARF structures. * Proper tests that directly compare the generated DWARF information to the expected results (possibly using something like [pyelftools](https://github.com/eliben/pyelftools) or llvm-dwarfdump) * A unified implementation for crate-local and crate-external items (which would possibly involve beefing up `ast_map::path` and metadata a bit) Any comments are welcome! Closes #1541 Closes #1542 (there might be other issues with function name prettiness, but this specific issue should be fixed) Closes #7715 (source locations for structs and enums are now read correctly from the AST)
This is a preliminary version of the Rust compiler, libraries and tools Source layout: librustc/ The self-hosted compiler libstd/ The standard library (imported and linked by default) libextra/ The "extras" library (slightly more peripheral code) libsyntax/ The Rust parser and pretty-printer rt/ The runtime system rt/rust_*.cpp - The majority of the runtime services rt/isaac - The PRNG used for pseudo-random choices in the runtime rt/bigint - The bigint library used for the 'big' type rt/uthash - Small hashtable-and-list library for C, used in runtime rt/sync - Concurrency utils rt/util - Small utility classes for the runtime. rt/vg - Valgrind headers rt/msvc - MSVC support rt/linenoise - a readline-like line editing library test/ Testsuite test/compile-fail - Tests that should fail to compile test/run-fail - Tests that should compile, run and fail test/run-pass - Tests that should compile, run and succeed test/bench - Benchmarks and miscellanea test/pretty - Pretty-printer tests test/auxiliary - Dependencies of tests compiletest/ The test runner librustpkg/ The package manager and build system librusti/ The JIT REPL librustdoc/ The Rust API documentation tool llvm/ The LLVM submodule libuv/ The libuv submodule rustllvm/ LLVM support code libfuzzer/ A collection of fuzz testers etc/ Scripts, editor support, misc