| Age | Commit message (Collapse) | Author |
|---|
|
Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>
|
|
Co-authored-by: Yong He <yonghe@outlook.com>
|
|
This PR is limited to documents.
All use of "Standard library" or "StdLib" are replaced with either "core module" or "standard modules", depending on the context.
|
|
|
|
Put space between control-flow and `(`. This is a default formatting
setting of Visual Studio 2019 and 2022. And we have been writing the
code in this style for a while.
|
|
|
|
* Correct case of windows.h includes
* Use Slang::SharedLibrary to load directx dlls
* s/max/std::max/
* Factor common OS code in calcHasApi
* Add DXIL test for compute/simple
* s/false/FALSE for calls to WinAPI functions
* Factor common OS code in gfxGetAdapters
* 2 missing headers
d3d12sdklayers for ID3DDebug
climits for UINT_MAX
* Define out unused function on Linux
* Only try to load Vulkan and CUDA on Windows or Linux
* simplify D3DUtil::getDxgiModule
* Remove WIN32_LEAN_AND_MEAN &co from source files
Add a global define
* Set WIN32_LEAN_AND_MEAN &friends in headers
Restore previous state also
* regenerate vs projects
|
|
After a lot of discussion, I'm backpedaling and making this document what the (main) conventions of the codebase *are* rather than trying to prescribe what I think they should be. In particular:
* Go back to `m_` for implementation-details member names, since that is the main convention in place for them
* Put the `k` prefix back on C-style `enum` types since that is how they are currently being defined.
My inclination is to just stick with what we have for now to avoid extended debates. Its a bit of an inconsistent mess, but its enough for getting work done.
|
|
* Add more design documents
This change adds a set of documents about the design/implementation of the Slang compiler intended for helping to onboard new contributors, explain some of the choices that go into the current implementation, and outline the broad strokes of some of our future feature goals.
As explained in the `README` for these docs, I don't expect them to be kept in sync with the code in the long run; there is no expectation that people making a PR for code changes also go and fix up these documents.
The purpose of these is to add a bit of a "historical record" of design choices and project goals to the project itself, so they can be browsed in a way that is more convenient than the issue tracker or source control history.
The "Coding Conventions" document is very much a first attempt, and I'm not 100% wedded to any of the decisions in there.
We haven't enforced consistent conventions so far, but the importance of having something in place will only grow with the number of contributors.
* Edits based on review
* Fix many typos (thanks @jsmall-nvidia)
* Change up some language in coding conventions based on discussions since when it was originally written. I'm still not 100% sure about some of the choices in there, but we need to get *something* established.
|
