- Wrap calls into linenoise in a mutex so that the functions don't have to be `unsafe` any more (fixes#3921)
- Stop leaking every line that linenoise reads.
- Handle the situation of `rl::complete(some_function); do spawn { rl::read(""); }` which would crash (`fail!` that turned into an abort, possibly due to failing with the lock locked) when the user attempted to tab-complete anything.
- Add a test for the various functions; it has to be run by hand to verify anything works, but it won't bitrot.
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
I plan on transitioning the standard logging/failing to using these macros soon. This is currently blocking on inner statics being usable in cross-crate situations (still tracking down bugs there), but this will hopefully be coming soon!
Additionally, I'd rather settle on a name now than later, so if anyone has a better suggestion other than `format_args`, I'm not attached to the name at all :)
These tests are being very flaky on the bots, and the reason is that files are
being created and then when attempted to get read they actually don't exist. I'm
not entirely sure why this is happening, but I also don't fully trust the
std::io implemention using @-boxes to close/flush/write files at the right time.
This moves the tests to using std::rt::io which is hopefully more robust and
something that we can actually reason about. Sadly, due to #8810, these tests
fail on windows, so they're all ignored on windows right now.
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
