The purpose of this macro is to further reduce the number of allocations which
occur when dealing with formatting strings. This macro will perform all of the
static analysis necessary to validate that a format string is safe, and then it
will wrap up the "format string" into an opaque struct which can then be passed
around.
Two safe functions are added (write/format) which take this opaque argument
structure, unwrap it, and then call the unsafe version of write/format (in an
unsafe block). Other than these two functions, it is not intended for anyone to
ever look inside this opaque struct.
The macro looks a bit odd, but mostly because of rvalue lifetimes this is the
only way for it to be safe that I know of.
Example use-cases of this are:
* third-party libraries can use the default formatting syntax without any
forced allocations
* the fail!() macro can avoid allocating the format string
* the logging macros can avoid allocation any strings
This is mostly for consistency, as you can now compare raw pointers in
constant expressions or without the standard library.
It also reduces the number of `ptrtoint` instructions in the IR, making
tracking down culprits of what's usually an anti-pattern easier.
Fixes issues #5557 and #8746.
This patch adds an additional family for struct-like variants, and encodes some struct-like aspects of such variants that can then be properly decoded by resolve.
Note that I am not 100% sure how this fix works, but it fixes the issue without breaking any of the tests on my machine.
The old documentation for for loops/expressions has been quite wrong since the change to iterators. This updates the docs to make them relevant to how for loops work now, if not very in-depth. There may be a need for updates giving more depth on how they work, such as detailing what method calls they make, but I don't know enough about the implementation to include that.
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#1541Closes#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 test has to be run by a human, to check inputs etc. Fortunately, it
won't bitrot (syntactically, or type-check-ly; it might bitrot
semantically), as it is designed so that the test runner compiles it with
`--cfg robot_mode`, which is used to disable the actual running of code.
- Removes a layer of indirection in the storage of the completion
callback.
- Handles user tab completion in a task in which `complete` hasn't been
properly. Previously, if `complete` was called in one task, and `read`
called in another, attempting to get completions would crash. This
makes the completion handlers non-ambiguously task-local only.
- Fix a mismatch in return values between the Rust code and linenoise.
r? @brson rustpkg now accepts most of rustc's command-line arguments and passes
them along to rustc when building or installing.
A few rarely-used arguments aren't implemented yet.
rustpkg doesn't support flags that don't make sense with rustpkg
(for example, --bin and --lib, which get inferred from crate file names).
Closes#8522
This way syntax extensions can generate unsafe blocks without worrying about them generating unnecessary unsafe warnings. Perhaps a special keyword could be added to be used in macros, but I don't think that's the best solution.
Currently if you use `format!` and friends in an `unsafe` block you're guaranteed to get some unused-unsafe warnings which is unfortunate. We normally do want these warnings, but I'm ok ignoring them in the case of compiler-generated unsafe blocks. I tried to do this in the least intrusive way possible, but others may have better ideas about how to do this.
This way syntax extensions can generate unsafe blocks without worrying about
them generating unnecessary unsafe warnings. Perhaps a special keyword could be
added to be used in macros, but I don't think that's the best solution.
The default buffer size is the same as the one in Java's BufferedWriter.
We may want BufferedWriter to have a Drop impl that flushes, but that
isn't possible right now due to #4252/#4430. This would be a bit
awkward due to the possibility of the inner flush failing. For what it's
worth, Java's BufferedReader doesn't have a flushing finalizer, but that
may just be because Java's finalizer support is awful.
The current implementation of BufferedStream is weird in my opinion, but
it's what the discussion in #8953 settled on.
I wrote a custom copy function since vec::copy_from doesn't optimize as
well as I would like.
Closes#8953
The default buffer size is the same as the one in Java's BufferedWriter.
We may want BufferedWriter to have a Drop impl that flushes, but that
isn't possible right now due to #4252/#4430. This would be a bit
awkward due to the possibility of the inner flush failing. For what it's
worth, Java's BufferedReader doesn't have a flushing finalizer, but that
may just be because Java's finalizer support is awful.
Closes#8953
rustpkg now accepts most of rustc's command-line arguments and passes
them along to rustc when building or installing.
A few rarely-used arguments aren't implemented yet.
rustpkg doesn't support flags that don't make sense with rustpkg
(for example, --bin and --lib, which get inferred from crate file names).
Closes#8522
update AST so that ExprBreak and ExprCont expressions contain names, not idents. Fixes#9047 and makes progress on #6993. Simplifies the compiler very slightly, should make it (infinitesimally) faster.
