This is needed so that the FFI works as expected on platforms that don't
flatten aggregates the way the AMD64 ABI does, especially for `#[repr(C)]`.
This moves more of `type_of` into `trans::adt`, because the type might
or might not be an LLVM struct.
Closes#10308.
This is needed so that the FFI works as expected on platforms that don't
flatten aggregates the way the AMD64 ABI does, especially for `#[repr(C)]`.
This moves more of `type_of` into `trans::adt`, because the type might
or might not be an LLVM struct.
Issue #8763 is about improving a particular error message.
* added case & better error message for "impl trait for module"
* added compile-fail test trait-impl-for-module.rs
* updated copyright dates
* revised compile-fail test trait-or-new-type-instead
(the error message for the modified test is still unclear, but that's a different bug https://github.com/mozilla/rust/issues/8767)
* added case & better error message for "impl trait for module"
* used better way to print the module
* switched from //error-pattern to //~ ERROR
* added compile-fail test trait-impl-for-module.rs
* revised compile-fail test trait-or-new-type-instead
(the error message for the modified test is still unclear, but that's a different bug)
* added FIXME to trait-or-new-type-instead
I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.
All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).
Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.
Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.
This also cracks down on exported methods from impl blocks and trait blocks. If you implement a private trait, none of the symbols are exported, and if you have an impl for a private type none of the symbols are exported either. On the other hand, if you implement a public trait for a private type, the symbols are still exported. I'm unclear on whether this last part is correct, but librustc will fail to link unless it's in place.
I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.
All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).
Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.
Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.
This was needed to access UEFI boot services in my new Boot2Rust experiment.
I also realized that Rust functions declared as extern always use the C calling convention regardless of how they were declared, so this pull request fixes that as well.
This replaces `*` with `..` in enums, `_` with `..` in structs, and `.._` with `..` in vectors. It adds obsolete syntax warnings for the old forms but doesn't turn them on yet because we need a snapshot.
#5830
This PR improves the single-stepping experience for if-expression (no more jumping into the *else* branch before entering the *then* branch, no more jumping to the end of the *else* branch after finishing the *then* branch). Unfortunately I don't know of a straight-forward way of writing automated tests for this. Suggestions welcome!
If a function is marked as external, then it's likely desired for use with some
native library, so we're not really accomplishing a whole lot by internalizing
all of these symbols.
If a function is marked as external, then it's likely desired for use with some
native library, so we're not really accomplishing a whole lot by internalizing
all of these symbols.
I've started working on this issue and pushed a small commit, which adds a range check for integer literals in `middle::const_eval` (no `uint` at the moment)
At the moment, this patch is just a proof of concept, I'm not sure if there is a better function for the checks in `middle::const_eval`. This patch does not check for overflows after constant folding, eg:
let x: i8 = 99 + 99;
Bare functions are another example of a scalar but non-numeric
type (like char) that should be handled separately in casts.
This disallows expressions like `0 as extern "Rust" fn() -> int;`.
It might be advantageous to allow casts between bare functions
and raw pointers in unsafe code in the future, to pass function
pointers between Rust and C.
Closes#8728
Now the privacy pass returns enough information that other passes do not need to duplicate the visibility rules, and the missing_doc implementation is more consistent with other lint checks.
Previously, the `exported_items` set created by the privacy pass was
incomplete. Specifically, it did not include items that had been defined
at a private path but then `pub use`d at a public path. This commit
finds all crate exports during the privacy pass. Consequently, some code
in the reachable pass and in rustdoc is no longer necessary. This commit
then removes the separate `MissingDocLintVisitor` lint pass, opting to
check missing_doc lint in the same pass as the other lint checkers using
the visibility result computed by the privacy pass.
Fixes#9777.
As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.
This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
Since the removal of privacy from resolve, this flag is no longer necessary to
get the test runner working. All of the privacy checks are bypassed by a special
item attribute in the privacy visitor.
Closes#4947
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).
There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.
C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.
Closes#8822Closes#10155
As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.
This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.
cc #10049Closes#8774
This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.
cc #10049Closes#8774
